Date: Fri, 5 Jun 2026 22:13:10 +0200
On 6/5/26 17:56, Thiago Macieira via Std-Proposals wrote:
> On Friday, 5 June 2026 07:40:52 Pacific Daylight Time Rainer Deyke via Std-
> Proposals wrote:
>> I'm not sure I buy that reasoning. Two iterators in a std::pair are
>
> No doubt, but this violates the rule of use of std::pair: NEVER.
>
> Don't add new APIs that return it. Create a new struct that assigns meaning to
> the two elements.
Nobody is suggesting adding new functions that return std::pair. But
multimap::equal_range already returns a std::pair when it should return
a std::ranges::subrange instead, and changing this would break a lot of
code. So the question becomes, how do we prevent that std::pair from
leaking into user code? A new replacement function? A conversion
function? Or do we drop the associative containers entirely and replace
them with something that does not use a std::pair as its value_type?
> On Friday, 5 June 2026 07:40:52 Pacific Daylight Time Rainer Deyke via Std-
> Proposals wrote:
>> I'm not sure I buy that reasoning. Two iterators in a std::pair are
>
> No doubt, but this violates the rule of use of std::pair: NEVER.
>
> Don't add new APIs that return it. Create a new struct that assigns meaning to
> the two elements.
Nobody is suggesting adding new functions that return std::pair. But
multimap::equal_range already returns a std::pair when it should return
a std::ranges::subrange instead, and changing this would break a lot of
code. So the question becomes, how do we prevent that std::pair from
leaking into user code? A new replacement function? A conversion
function? Or do we drop the associative containers entirely and replace
them with something that does not use a std::pair as its value_type?
-- Rainer Deyke - rainerd_at_[hidden]
Received on 2026-06-05 20:13:19
