Fix std::pair std::is_copy_assignable behavior

[Bo Persson]

François Dumont skrev 2013-04-19 22:30:
> 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.
>

Sorry for barging in like this, but the C++11 standard has some specific 
requirements for those constructors, like:

"Remarks: If U is not implicitly convertible to first_type or V is not 
implicitly convertible to second_type this constructor shall not 
participate in overload resolution."

One rather obvious way of fulfilling this is to use std::enable_if for 
those constructors.

However, I can't see any similar wording for enabling or disabling 
is_copy_assignable. The standard is rather abstract at this point though.


Bo Persson