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.
