This is the mail archive of the
mailing list for the GCC project.
Re: Fix std::pair std::is_copy_assignable behavior
- From: François Dumont <frs dot dumont at gmail dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 19 Apr 2013 22:30:09 +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>
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 126.96.36.199. 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.
Ok to commit ?