Fix std::pair std::is_copy_assignable behavior

[François Dumont]

On 04/17/2013 10:02 PM, Paolo Carlini wrote:
> Hi,
>
> On 4/17/13 8:43 PM, François Dumont wrote:
>> On 04/17/2013 09:18 PM, Paolo Carlini wrote:
>>> On 4/17/13 8:10 PM, François Dumont wrote:
>>>> Hi
>>>>
>>>>     Here is an other proposal to fix 
>>>> std::is_copy_assignable<std::pair<>>.
>>> Sorry, I'm still missing something very, very basic: which behavior 
>>> is conforming, the current one or what we would get instead? If the 
>>> former, is there a DR arguing for the latter?
>>>
>>> Paolo.
>>>
>>     The behavior I am targeting is 
>> std::is_copy_asignable<std::pair<const int, int>> to be 
>> std::false_type for instance. I have added test for many other use 
>> cases. More generally I need that when std::is_copy_assignable<T> is 
>> std::true_type then writing a = b, with a and b being T, does compile.
>>
>>     Otherwise this patch just make std::pair match the Standard 
>> requirements like at 20.3.2.17. Do you want me to add a bug report in 
>> Bugzilla first ?
> I'm not talking about GCC's Bugzilla, I meant an ISO DR: if we don't 
> have a DR and preferably a vague support of LWG people, I think we 
> should not change the behavior of our std::is_copy_assignable only 
> because it helps our implementation of other facilities.
>
> Paolo.
>
Hi

     I check again the Standard and I really can't see any problem with 
the patch. As far as I understand it having std::is_copy_assignable 
being true is not a guaranty that the expression will compile but making 
std::pair is_copy_assignable friendly doesn't violate it neither.

     I also see that std::pair is already using std::enable_if to 
disable some constructors. I check the ChangeLog and it was not 
associated to a any ISO DR. I don't know why at that moment the same 
kind of modification hadn't been done for the assignment operators but 
the patch is not doing more than what has been done at that time.

     Ok to commit ?

François