This is the mail archive of the
mailing list for the libstdc++ project.
Re: DR 1402 generalization
- From: François Dumont <frs dot dumont at gmail dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: Paolo Carlini <paolo dot carlini at oracle dot com>, Jonathan Wakely <jwakely dot gcc at gmail dot com>, Daniel Krügler <daniel dot kruegler at gmail dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 05 Apr 2013 22:18:15 +0200
- Subject: Re: DR 1402 generalization
- References: <511EA09D dot 8000704 at gmail dot com> <CAGNvRgCFOyoRmyGn5nDGR1xPkdVGiA15gxQX_34jpWb3PuDJfA at mail dot gmail dot com> <511F5589 dot 6070906 at gmail dot com> <CAGNvRgC8PKzPewop5vBiq3K-j2Skte5-f-Shp_8vDEf7LucXNg at mail dot gmail dot com> <51365756 dot 5060404 at gmail dot com> <CAH6eHdQbcx6c_WKzN1V48jmLGNB=WuoystUtOmwydynJ5xGfYg at mail dot gmail dot com> <CAGNvRgA8-s_uSpVdZz9imELnT3-E3+4VKb=T6+PvwN8O5LHdhg at mail dot gmail dot com> <5137ADE2 dot 4030802 at gmail dot com> <CAGNvRgBO0tnBPddyNEkUzPm5=GyrJ-+=yS_dJNtz8fVkwKopeg at mail dot gmail dot com> <CAGNvRgB=Y0Mbt-q4664WO+ZGeAAznu5M_NWq30WXUqEKV2cKxQ at mail dot gmail dot com> <513A4E32 dot 4030804 at gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1303082151050 dot 14163 at stedding dot saclay dot inria dot fr> <51438F19 dot 3010704 at gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1303152243570 dot 16016 at stedding dot saclay dot inria dot fr> <514CC0BF dot 4060701 at gmail dot com>
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
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.
On 03/22/2013 09:36 PM, François Dumont wrote:
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
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 ?