This is the mail archive of the
mailing list for the libstdc++ project.
Re: Fix std::pair std::is_copy_assignable behavior
- From: Bo Persson <bop at gmb dot dk>
- To: libstdc++ at gcc dot gnu dot org
- Date: Sat, 20 Apr 2013 08:20:16 +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>
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:
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.
On 04/17/2013 09:18 PM, Paolo Carlini wrote:
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.
On 4/17/13 8:10 PM, François Dumont wrote:
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?
Here is an other proposal to fix
Otherwise this patch just make std::pair match the Standard
requirements like at 184.108.40.206. Do you want me to add a bug report
in Bugzilla first ?
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
However, I can't see any similar wording for enabling or disabling
is_copy_assignable. The standard is rather abstract at this point though.