[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