Re: __rvalref overloads causing ambiguities

[Paolo Carlini <pcarlini at suse dot de>]

Hi Jonathan,

>That's true for most, but not for std::pair, so making the rvalref ctor a
>template is necessary to prevent this failing:
>
>#include <utility>
>
>struct A {
>    template <typename B> operator B() const { return B(); }
>};
>
>int main()
>{
>    A a;
>    std::pair<int,int> v(a);
>    v = a;
>}
>
>(should probably be added to the testsuite, I'll prepare it at lunchtime
>if noone beats me to it)
>  
>
Consider this kind of additions to the testsuite preapproved for
v7-branch. Thanks.

>>I think the new error message is OK (or at least as OK as error messages
>>in the STL ever get...)
>>    
>>
>You can use the _SameTypeConcept from bits/boost_concept_check to give a
>better message e.g.
>
>      template <typename _Moveable>
>        deque(__gnu_cxx::__rvalref<_Moveable> __x)
>        : _Base(__x.__ref.get_allocator(), 0)
>        {
>          __glibcxx_function_requires(_SameTypeConcept<deque, _Moveable>)
>          this->swap(__x.__ref);
>        }
>
>This only works when concept-checking is enabled, but it's better than nothing.
>  
>
Yes, I was also vaguely considering this possibility (we added some of
those also in the occasion of the extension involving rebinding of
allocators): in case you can verify that the error messages are
*actually* better, please consider this kind of patch preapproved too.

Paolo.