Re: [PATCH] Do not use tuple-like interface for pair in unordered containers

["François Dumont" <frs.dumont@gmail.com>]

Hi

     Sorry for the delay, I had just miss this message.

     I think you are clearly more expert than me for the changes you 
propose. I had a look at the patch and it seems just fine as it keeps 
the forwarding as expected. Nice simplification in 
_NodeBuilder<_Select1st>, we indeed only need to deal with std::pair 
type in this case.

François


On 26/07/21 7:25 pm, Jonathan Wakely wrote:
> On 23/07/21 19:21 +0100, Jonathan Wakely wrote:
>> I've been experimenting with this patch, which removes the need to use
>> std::tuple_element and std::get to access the members of a std::pair
>> in unordered_{map,multimap}.
>>
>> I'm in the process of refactoring the <utility> header to reduce
>> header dependencies throughout the library, and this is the only use
>> of the tuple-like interface for std::pair in the library.
>>
>> Using tuple_element and std::get resolved PR 53339 by allowing the
>> std::pair type to be incomplete, however that is no longer supported
>> anyway (the 23_containers/unordered_map/requirements/53339.cc test
>> case is XFAILed). That means we could just define _Select1st as:
>>
>>  struct _Select1st
>>  {
>>    template<typename _Tp>
>>      auto
>>      operator()(_Tp&& __x) const noexcept
>>      -> decltype(std::forward<_Tp>(__x).first)
>>      { return std::forward<_Tp>(__x).first; }
>>  };
>>
>> But the approach in the patch seems OK too.
>
> Actually I have a fix for PR 53339 so that we can support incomplete
> types again. So we don't want to access the .first member in the
> return type, as that requires a complete type.
>