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.
