[libcxx-commits] [libcxx] [libc++] avoid using `ranges::advance` and `ranges::next` in all algorithms (PR #179095)

[Nikolas Klauser via libcxx-commits]

https://github.com/philnik777 requested changes to this pull request.

> I actually think this approach makes a lot of sense.
> 
> Ranges essentially introduced multiple new functions that do different things, and it gave them the same name. So even outside of this ambiguity issue, I feel like our internal `_IterOps` are clearer in intent if we clarify what operation we actually mean inside our algorithms.

Would you also be in favour of introducing internal versions of `std::move` because there are two functions with the same name that do different things?

> The fact that this resolves the ambiguity is a nice side effect, I guess, but I mostly like this change because it stops conflating two different operations under the same name.

I _really_ don't see the conflation here. I can't find a single place in this patch where it's not immediately obvious what's going on. IMO it's actually rather confusing that there is `__next_n` now, which may not actually take an `n`.

> Furthermore, I think it makes more sense take this patch than #177773 in the current context, since:
> 
>     * #177773 is modifying a public API
> 
>     * #177773 favours a specific resolution to the LWG issue, which struggles to gain consensus at the moment
>       In other words, this patch allows us to fix the issue reported, clean up our code (IMO) and it doesn't require changing a public API, which would make us arguably non-conforming.

I agree that it makes more sense, but IMO this should be a wontfix, and the LWG thread seems to agree now. IMO we should wait for the LWG issue to be resolved before making our code base worse. If we want to fix anything, we should avoid using `ranges::` algorithms in non-`ranges` code.

https://github.com/llvm/llvm-project/pull/179095