Fix std::pair std::is_copy_assignable behavior
Sat Apr 20 06:58:00 GMT 2013
2013/4/20 Bo Persson <firstname.lastname@example.org>:
> François Dumont skrev 2013-04-19 22:30:
>> 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
That is right, but this could only be realized (at least my normal
language means) by constraining templates.
> However, I can't see any similar wording for enabling or disabling
> is_copy_assignable. The standard is rather abstract at this point though.
This wording does not exist, because the move/copy assignment
operators cannot be constrained by normal means, because they cannot
be templates according to the language and because the library cannot
introduce a constrained base class for pair, because that would be
user-observable. The base class technique would be possible for tuple,
though. As far as I remember the only reason why this approach does
not work with pair is, because the type of &std::pair<int, int>::first
would no longer be int std::pair<int, int>::* but int __pairbase<int,
More information about the Libstdc++