DR 1402 generalization

[François Dumont]

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