Date: Sun, 7 Jun 2026 11:43:51 +0200
On 6/7/26 01:13, Giuseppe D'Angelo via Std-Proposals wrote:
> 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.
It's a concern if those 3rd party containers want to implement the
Associative Container Named Requirements, and be used in a generic
context that requires the Associative Container Named Requirements.
Either the new function is added to the Named Requirements (meaning that
existing containers no longer meet the Requirements) or it is not
(meaning that generic code cannot use this function).
> 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.
It's a concern if those 3rd party containers want to implement the
Associative Container Named Requirements, and be used in a generic
context that requires the Associative Container Named Requirements.
Either the new function is added to the Named Requirements (meaning that
existing containers no longer meet the Requirements) or it is not
(meaning that generic code cannot use this function).
-- Rainer Deyke - rainerd_at_[hidden]
Received on 2026-06-07 09:44:03
