Value type of map need not be default copyable

[Jonathan Wakely]

On 9 August 2012 09:35, Paolo Carlini wrote:
>
> When it does, and the corresponding PR will be *ready* we'll reconsider the
> issue. After all the *months and months and months* spent by the LWG adding
> and removing members from pair and tweaking everything wrt the containers
> and issues *still* popping up (like that with the defaulted copy constructor
> vs insert constraining), and with the support for scoped allocators still
> missing from our implementation, we are not adding members to std::pair such
> easily. Sorry, but personally I'm not available now to further discuss this
> specific point.

I'm with Paolo on this. No additional (non-standard) constructors in
std::pair please.

If it was possible to do without changing the ABI I'd include <tuple>
in the unordered containers anyway, when add scoped allocator support,
because std::tuple already knows how to avoid the EBO for 'final'
allocators (PR 51365).  I'd do the same in the other containers except
that they need to work in C++03 mode without std::tuple.

I think we should consider std::tuple almost as fundamental as
std::pair and shouldn't jump through hoops to avoid using it.  It's
already included by <memory> for example, to implement
std::unique_ptr, and I recently made changes to make it easier to use
std::unique_ptr internally, so we shouldn't be afraid of std::tuple
getting used more widely.