Copy Constructor DIP and implementation

[aliak]

On Monday, 17 September 2018 at 23:32:39 UTC, Jonathan M Davis 
wrote:
> On Monday, September 17, 2018 5:07:22 PM MDT Manu via 
> Digitalmars-d-announce wrote:
>> [...]
>
> Except that @implicit could be introduced for other 
> constructors without having it on copy constructors, and the 
> fact that copy constructors will require it is just going to 
> cause bugs, because plenty of folks are going to forget to use 
> it and end up with the default copying behavior instead of 
> their custom copy constructor being used. Good testing should 
> find that pretty quickly, but it's almost certainly going to be 
> a common bug, and it has no need to exist. It's all there in 
> order to avoid breaking code that's likely only theoretical and 
> not something that actual D code bases have done. And if there 
> is a stray code base that did it, it's certainly going to be in 
> the extreme minority, and the code will almost certainly work 
> as a proper copy constructor anyway, since that's pretty much 
> the only reason to write such a constructor. So, we'd be trying 
> to avoid breaking very rare code by introducing a feature that 
> will definitely cause bugs. IMHO, it would be _far_ better to 
> just use a transitional -dip* compiler flag like we have with 
> other DIPs. It would also give us the benefit of being able to 
> bang on the implementation a bit before making it the normal 
> behavior.
>
> We can still add @implicit to other constructors for implicit 
> construction with a later DIP (assuming that Walter and Andrei 
> could be convinced of it). I don't see how having it on copy 
> constructors really helps with that. It just means that the 
> attribute would already be there, not that it would necessarily 
> ever be used for what you want, and _not_ having it on copy 
> constructors wouldn't prevent it from being used for implicit 
> construction if such a DIP were ever accepted. So, while I 
> understand that you want implicit construction, I think that 
> it's a huge mistake to tie that up into copy constructors, 
> particularly since it really doesn't make sense to have copy 
> constructors that aren't implicit, and having @implicit for 
> copy constructiors is going to cause bugs when it's forgotten.
>
> - Jonathan M Davis

I think this can be made in to a compiler error.

The logic would be if there is any copy constructor defined (by 
copy constructor I mean a constructor that gets passed an object 
that can be used to construct typeof(this) - so ignore definition 
in DIP), then default copy construction is a compiler error 
unless an @implicit copy constructor is defined.

struct A {
   this(ref A) {}
}

A a;
A b = a; // error, cannot implicitly copy because an explicit one 
is provided
A c = A(a); // ok

This will break compilation of current code that has an explicit 
copy constructor, and the fix is simply to add the attribute 
@implicit.