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

[Nikolas Klauser via libcxx-commits]

philnik777 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.

`__move` exists because it's a completely private interface. That has nothing to do with this patch and just avoids the question.

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

I see that people think this iterator should be rejected, which would make this patch worthless in terms of fixing the reported issue, since we're using `ranges::` algorithms inside the `flat_` containers. There is agreement that there is an issue. That people don't like the current resolution isn't exactly uncommon. Also FWIW I do agree with that direction.

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

WDYM there is no clear distinction? There are classic interfaces like `flat_map(InputIterator, InputIterator)` and ranges ones like `insert_range`. It's the same distinction as with the classic vs. ranges algorithms.

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

They are clearly querying for information. I can't tell you why I expect a functor when I hear `__next_until`, but I do.

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

Thanks, nobody will understand me without this clarification.


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