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

[RazvanN]

On Wednesday, 9 January 2019 at 08:18:58 UTC, Dru wrote:
>> Why would you need a default copy constructor? If there aren't 
>> any copy constructors defined, the compiler will just blit the 
>> fields. Generating
>
>
> For the sake of consistency.
> Imagine if the user explicitly calls or uses the address of the 
> (generated) copy ctor,
> then a struct change is made and the copy ctor is "no longer 
> needed" because you can blit.
> The user code that explicitly used the constructor is now 
> broken.

Consistency with what? How would you take the address of the copy 
constructor?
&a.__ctor? As you can see, you have to use the infamous `__` to 
do that so you should probably avoid it. Other than that what 
other use cases can be made for the generation of a default copy 
constructor and implicitly breaking most of the code that uses 
structs to pass by value to functions?

If you want to implicitly declare default copy constructors, you 
have to define all variants: mutable->mutable, const->const, 
immutable->immutable, shared->shared, all inout permutations etc. 
just to have backwards compatibility with the code that already 
uses structs. A horde of copy constructors to support a niche 
case. On the other hand, the current design is elegant as it does 
not touch already existent code and it generates copy 
constructors as they are indeed needed.

>> a single default copy constructor is not enough.
>
> how about:
>
> this(ref const T other);
> immutable this(ref const T other);