Il 05/06/26 12:09, Rainer Deyke via Std-Proposals ha scritto:
> An additional member function (true_equal_range?) could be added to the
> existing [unordered] associative containers. This is less than ideal
> because it leaves user-defined [unordered] associative containers behind.

This isn't a concern, is it? Actually, those 3rd party containers could
be returning ranges::subrange today, instead of iterator pairs, simply
because they may not be bound by the same API compatibility promise that
binds the Standard Library.

(Ultimately what you're asking is for a time machine, and have C++98
Standard Library APIs return C++20 datatypes.)


> Overloads for std::begin and std::end could be added for std::pairs of
> iterators. This would be my preferred solution, but it could break
> existing code. It also prevents treating std::pair<T, T> as a range of
> two elements of type T.

This sounds like a bad idea. For instance a pair of two pointers (which
are two iterators) isn't necessarily representing a range over them.
Having such a pair satisfy the range concept(s) is dangerous.


> A constructor that takes a std::pair of iterators could be added to
> std::ranges::subrange. This should be a fairly safe addition to the
> standard, although it can break user code in pathological cases.

This seems straightforward to add. Any possible breakage can be
mitigated by making this constructor explicit and/or tagged.


> Add a free function to convert a std::pair of iterators into a
> std::ranges::subrange. This is the safest solution; highly unlikely to
> break user code and any user code it does breaks is the fault of the user.

This seems just more confusing than adding a constructor to
ranges::subrange.


My 2 c,
--
Giuseppe D'Angelo