Copy Constructor DIP and implementation

[tide]

On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis 
wrote:
> Basically, @implicit is being proposed out of fear that 
> someone, somewhere wrote a constructor that had what would be a 
> copy constructor if D had them instead of postblit constructors 
> and that that code would break with the DIP. Does anyone expect 
> that such a constructor would be intended as anything other 
> than a copy constructor (albeit one that has to be called 
> explicitly)? And does anyone really think that such 
> constructors are at all common, given that the correct way to 
> handle the problem in D right now is the postblit constructor? 
> We're talking about introducing an attribute that should be 
> unnecessary, which will be annoying to use, and which will be 
> error-prone given the bugs that you'll get if you forget to 
> mark your copy constructor with it. And it's all to avoid 
> breaking a theoretical piece of code that I would think that we 
> could all agree is extremely rare if it exists in any real D 
> code base at all. Simply using a transitional compiler switch 
> like we have with other DIPs would make _way_ more sense than 
> burdening the language with an unnecessary attribute that's 
> just going to make it easier to write buggy code. This is 
> clearly a case of making the language worse long term in order 
> to avoid a theoretical problem in the short term.
>
> - Jonathan M Davis

 From what I've read, the copy constructor can be used with 
different types:

struct B
{
}

struct A
{
     @implicit this(ref B b)
     {
     }
}


B foo();

A a;
a = foo(); // ok because of @implicit
a = A(foo()); // ok without @implicit

That's why it exists, otherwise I wouldn't want two types to be 
implicitly convertible unless i explicitly tell it to be implicit.