DIP 1018--The Copy Constructor--Community Review Round 1

[RazvanN]

On Saturday, 5 January 2019 at 14:54:41 UTC, Dru wrote:
>> The copy constructor is generated, only if there are copy 
>> constructors for some fields that need to be called. The idea 
>> is that if a struct defines a copy constructor, it cannot be 
>> blitted in any circumstances; the copy constructor should 
>> always be used.
>
> I offer a simpler logic:
> A "default" copy constructor is always generated,
> except when the user defines a constructor of the same 
> signature.
> Effectively the user can override the default.
>
Why would you need a default copy constructor? If there aren't 
any copy constructors defined, the compiler will just blit the 
fields. Generating
a single default copy constructor is not enough. Consider:

struct A
{
     int a;
}

fun(immutable A a) {}

void main()
{
     immutable A a;
     fun(a);
}

If we define a single copy constructor like you suggested, then 
this will not work because you have immutable to immutable copy. 
In this situation it is best to leave the copying to the existing 
mechanism.

>
>
>> It cannot call it, because the constructor receives a 
>> reference and you are passing an rvalue. That is not even a 
>> copy constructor, but a regular constructor, so if you want 
>> the compiler to call it, simply delete the ref.
>
> yes not related to the DIP
> just wondering why block the option to pass rvalue by ref

Currently, the only solution to this is to bind the rvalue to an 
lvalue: (B __tmp = B(); tmp), but this is problematic because 
assignment has side effects while in the original case a move is 
performed. It is not an unsolvable problem, but it would lead to 
unexpected behavior in some cases.