This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ 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: Wed, 17 Apr 2013 21:43:21 +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>
On 04/17/2013 09:18 PM, Paolo Carlini wrote:
On 4/17/13 8:10 PM, François Dumont wrote:
Hi
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?
Paolo.
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 20.3.2.17. Do you want me to add a bug report in
Bugzilla first ?
François