On 04/17/2013 10:02 PM, Paolo Carlini wrote:
Hi,
On 4/17/13 8:43 PM, François Dumont wrote:
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 ?
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.
Paolo.
Hi
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 ?
François