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

[via libcxx-commits]

huixie90 wrote:

> 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?

We are already doing this. We have `std::__move` and it is being used in several algorithms. Plus, `std::move` is less a problem because the two different meanings take different number of arguments.
 
>  __next_n now, which may not actually take an n.

Then let's rename it to something else then.

> the LWG thread seems to agree now

Where do you think it seems to agree? I don't think anyone agrees with the proposed resolutions. There are momentum to agree on modify the `sentinel_for` concept, which is rather big change and I am sure it at least needs a paper. I don't think this LWG will resolve any time soon. (As Tim pointed out, he would like to see first the deployment of `std::span` case)

> If we want to fix anything, we should avoid using ranges:: algorithms in non-ranges code.

I don't think there is clear distinction now in new containers. They accept both ranges and non-ranges code at the same time. Their spec is mostly defined in `ranges` term, however maintain the compatibility with classical containers.

> I don't think __next_until is any clearer. I actually think it's significantly worse, since it sounds like you're passing a functor of some kind.

I think `until` is much clearer. I don't think `until` has been associated with functor anywhere, for example, `is_sorted_until`,  `is_heap_until `, etc... they are expecting a position.  btw, functor is not a thing in c++, if anything, the closest thing to what it means is any object that has `transform` semantic, like, ranges, optional. 

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