This is the mail archive of the
mailing list for the libstdc++ project.
Re: Fix std::pair std::is_copy_assignable behavior
- From: Daniel Krügler <daniel dot kruegler at gmail dot com>
- To: Bo Persson <bop at gmb dot dk>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Sat, 20 Apr 2013 08:58:01 +0200
- Subject: Re: Fix std::pair std::is_copy_assignable behavior
- References: <51687815 dot 6030507 at gmail dot com> <516EF3B1 dot 2050401 at gmail dot com> <516EF57A dot 9030607 at oracle dot com> <516EFB59 dot 10105 at gmail dot com> <516EFFC7 dot 6070001 at oracle dot com> <5171A951 dot 7080801 at gmail dot com> <517233A0 dot 4090007 at gmb dot dk>
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,