Copy Constructor DIP and implementation

[Jonathan M Davis]

On Wednesday, September 12, 2018 1:18:11 PM MDT Gary Willoughby via 
Digitalmars-d-announce wrote:
> On Wednesday, 12 September 2018 at 16:40:45 UTC, Jonathan M Davis
>
> wrote:
> > Ultimately, I expect that if we add any attribute for this,
> > people coming to D are going to think that it's downright
> > weird, but if we're going to have one, if we go with @implicit,
> > we're future-proofing things a bit, and personally, thinking
> > about it over time, I've found that it feels less like a hack
> > than something like @copy would. If we had @copy, this would
> > clearly forever be something that we added just because we has
> > postblit constructors first, whereas @implicit at least _might_
> > be used for something more.
>
> That does actually make a lot of sense. Isn't there any way these
> constructors could be inferred without the attribute?

As I understand it, the entire point of the attribute is to avoid any
breakage related to constructors that have a signature that matches what a
copy constructor would be. If we didn't care about that, there would be no
reason to have an attribute. Personally, I think that the concerns about
such possible breakage are overblown, because it really wouldn't make sense
to declare a constructor with the signature of a copy constructor unless you
intended to use it as one (though right now, it would have to be called
explicitly). And such code shouldn't break if "explicit" copy constructors
then become "implicit" copy constructors automatically. However, Andrei does
not believe that the risk is worth it and insists that we need a way to
differentiate between the new copy constructors and any existing
constructors that happen to look like them. So, there won't be any kind
inference here. If we were going to do that, we wouldn't be adding the
attribute in the first place.

- Jonathan M Davis