This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: DR 1402 generalization

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/, 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.


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 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 ?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]