Looks like this problem is not having a lot of success :-)
I finally had a regression with my little modification of gcc/cp/call.c
to generalize DR 1402 to copy semantic.
In testsuite/23_containers/unordered_set/55043.cc, in debug mode the
following static assertion fails:
static_assert(!std::is_copy_constructible<uim_rval>::value, "is not
copyable");
With my modification gcc starts considering the constructor from a
normal unordered_set instance which is not deleted.
So we fall back to the problem of gcc not being SFINAE friendly enough.
Is it a know issue ?
I still think that proposing a generalization of DR 1402 would be nice
to simplify code but I now realize that the core issue is a compiler
limitation. I add gcc mailing list just in case someone would like to react.
François
On 03/22/2013 09:36 PM, François Dumont wrote:
Hi
I completed my little study on the
std::is_copy_assignable<std::pair<const int, int>> issue.
On 03/15/2013 11:31 PM, Marc Glisse wrote:
So instead of having deleted functions we get the same as if there
was no declaration? I thought this had already been proposed and
rejected at the time (some people love features that prevent programs
from compiling), but maybe it wasn't exactly the same. In any case,
still worth trying again with the std::pair example.
I think it has been discuss indeed Marc. Surely during review of
DR 1402 which resolution is exactly what I had in mind but limited to
the move constructor and move assignment operator.
It hasn't been difficult for me then to tweak the joust function
in gcc/cp/call.c to remove this limitation of the DR 1402 resolution.
I then changed std::pair to have a defaulted copy and move assignment
operators and run libstdc++ tests without any regression. A test on
std::pair<int&, int&> also worked. So it doesn't seem to be a too
dangerous proposal.
Note that thanks to DR 1402 already applied to gcc I think that
using a defaulted move assignment operator for std::pair or std::tuple
wouldn't be a problem. Do you known why it is not defaulted ?
However it had no impact on the wrong result of
std::is_copy_assignable<std::pair<const int, int>>. I realized that
this problem is rather a compiler limitation. I thought that
std::is_copy_assignable was using some compiler support to detect that
copy assignment is deleted or not but it is not, it is simply checking
that the operator = (const T&) expression has a match. The problem is
that gcc do not check that the matches are not ill formed. Could gcc
detect in a SFINAE context that the expression is invalid ? Should I
file a PR for that or is it a known issue ?
I also find surprising that std::is_copy_assignable<int&> is true.
It introduces a little inconsistency between what the compiler
consider as copy assignable and the library feedback. Despite
std::is_copy_assignable<int&> being true the compiler is not able to
generate a copy assignment operator for std::pair<int&, int&>. Maybe I
am confusing std:::is_copy_assignable purpose with the
std::is_trivially_copy_assignable one ?
François
