Copy Constructor DIP and implementation

[Jonathan M Davis]

On Monday, September 17, 2018 5:14:28 PM MDT tide via Digitalmars-d-announce 
wrote:
> 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.

No. That wouldn't be a copy constructor. The DIP specifically says that "A
declaration is a copy constructor declaration if it is a constructor
declaration annotated with the @implicit attribute and takes only one
parameter by reference that is of the same type as typeof(this)." So, it
clearly must be the same type and can't be a different type.

It also says that "The copy constructor needs to be annotated with @implicit
in order to distinguish a copy constructor from a normal constructor and
avoid silent modification of code behavior." Andrei confirmed that that's
why @implicit was there in the last major discussion on the DIP in the
newsgroup. So, it's clearly there in order to avoid breaking existing code -
code which is going to be _extremely_ rare.

- Jonathan M Davis