This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix std::pair std::is_copy_assignable behavior

François Dumont skrev 2013-04-19 22:30:
On 04/17/2013 10:02 PM, Paolo Carlini wrote:

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:

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?


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 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.



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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]