Re: Value type of map need not be default copyable

[Paolo Carlini <paolo dot carlini at oracle dot com>]

On 08/04/2012 03:26 PM, Marc Glisse wrote:
> On Sat, 4 Aug 2012, Paolo Carlini wrote:
>
> > .. note anyway, that only the new testcase was failing, no 
> > regressions on pre existing testcases.
>
> What I am seeing is a different testcase (with the same name but in a 
> different directory) failing, because:
>
>   typedef std::pair<const rvalstruct,rvalstruct> V;
>   static_assert(std::is_constructible<V, V&&>::value,"too bad");
>
> and it makes sense, since you end up having to construct a rvalstruct 
> from a rvalstruct const&&.
Oops, you are right, sorry. To be clear, the testcase which was failing 
with the patch applied is (just check testresults, many examples) is:

  23_containers/map/element_access/2.cc

> make_pair constructs a pair without const, from which a pair with 
> const is constructible, though I am surprised it doesn't fail 
> somewhere further. I don't know what the right solution is, maybe 
> something emplace-like. In any case, make_pair is unlikely to be right.
I'm not sure to understand which specific testcase you are discussing, 
but for sure we don't want regressions. I agree that we should assume a 
priori that the standard is right, but correcting the make_pair should 
not lead to failures elsewhere (unless a proper analysis establishes 
that the existing testcases are wrong)

Paolo.