[libcxx-commits] [libcxx] [libc++] avoid using `ranges::advance` and `ranges::next` in all algorithms (PR #179095)
via libcxx-commits
libcxx-commits at lists.llvm.org
Mon Feb 9 05:16:46 PST 2026
huixie90 wrote:
> 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.
for example, this paragraph https://eel.is/c++draft/flat.map#modifiers-6
The API looks like it is a classical API
``` cpp
template<class InputIterator>
constexpr void insert(InputIterator first, InputIterator last);
```
But the specification is using `ranges` API
```cpp
auto zv = views::zip(c.keys, c.values);
auto it = ranges::unique(zv, key-equiv(compare)).begin();
auto dist = distance(zv.begin(), it);
c.keys.erase(c.keys.begin() + dist, c.keys.end());
c.values.erase(c.values.begin() + dist, c.values.end());
```
That is why I am saying it is no clear distinction.
> 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.
I agree if the LWG issue is resolved and fixed, it is less convincing to apply this patch. But I still think it is an improvement. For example, the abstraction layer interface is asymmetric between the two policies in `IterOps::advance`. The classical version only works for (iter, n) , but ranges version works for (iter, n) and (iter, sent), which is not the best abstraction.
> 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.
Which direction are you referring to? I think I do agree with the latest proposed direction which bans integer-like from `sentinel_for` but I think it requires some efforts to convince people and I don't see how such major change can be resolved in an LWG issue.
> I can't tell you why I expect a functor when I hear __next_until, but I do.
Sure, if we decide to further on this approach, we can figure out a better name that everyone likes. btw, I did some code search within libcxx, i think we used `until` mainly for two kinds of things: 1. iterator/sentinel 2. time_point.
https://github.com/llvm/llvm-project/pull/179095
More information about the libcxx-commits
mailing list