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

[Jonathan Wakely]

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.

We don't need _Select2nd because it's only needed in
_NodeBuilder::_S_build, and that can just access the .second member of
the pair directly. The return type of that function doesn't need to be
deduced by decltype, we can just expose the __node_type typedef of the
node generator, or we could add this to the node generators:

   using result_type = __node_type*;

None of these changes are essential, but they allows other headers in
the library to be kept smaller, so they compile faster, and only
declare the components that are actually require by the standard.

What do you think?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 9186 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20210723/16e66a5d/attachment.bin>