Copy Constructor DIP and implementation

[Jonathan M Davis]

On Monday, September 17, 2018 5:07:22 PM MDT Manu via Digitalmars-d-announce 
wrote:
> On Mon, 17 Sep 2018 at 13:55, 12345swordy via Digitalmars-d-announce
>
> <digitalmars-d-announce at puremagic.com> wrote:
> > On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
> > > Hello everyone,
> > >
> > > I have finished writing the last details of the copy
> > > constructor DIP[1] and also I have published the first
> > > implementation [2]. As I wrongfully made a PR for the DIP queue
> > > in the early stages of the development of the DIP, I want to
> > > announce this way that the DIP is ready for the draft review
> > > now. Those who are familiar with the compiler, please take a
> > > look at the implementation and help me improve it!
> > >
> > > Thanks,
> > > RazvanN
> > >
> > > [1] https://github.com/dlang/DIPs/pull/129
> > > [2] https://github.com/dlang/dmd/pull/8688
> >
> > The only thing I object is adding yet another attribute to a
> > already big bag of attributes. What's wrong with adding keywords?
> >
> > -Alexander
>
> I initially felt strongly against @implicit, it shouldn't be
> necessary, and we could migrate without it.
> But... assuming that @implicit should make an appearance anyway (it
> should! being able to mark implicit constructors will fill a massive
> usability hole in D!), then it doesn't hurt to use it eagerly here and
> avoid a breaking change at this time, since it will be the correct
> expression for the future regardless.

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