This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
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>
- Date: Fri, 22 Mar 2013 21:36:15 +0100
- Subject: 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>
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