Copy Constructor DIP and implementation

[Jonathan M Davis]

On Wednesday, September 12, 2018 5:55:05 PM MDT Nicholas Wilson via 
Digitalmars-d-announce wrote:
> On Wednesday, 12 September 2018 at 23:36:11 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, September 12, 2018 5:17:44 PM MDT Nicholas Wilson
> >
> > via Digitalmars-d-announce wrote:
> >> it seems that even if we were to want to have @implicit as an
> >> opposite of C++'s explicit it would _always_ be present on
> >> copy-constructors which means that @implicit for copy
> >> constructors should itself be implicit.
> >
> > Oh, yes. The whole reason it's there is the fear that not
> > requiring it would break code that currently declares a
> > constructor that would be a copy constructor if we didn't
> > require @implicit. So, if the DIP is accepted, you _could_
> > declare a constructor that should be a copy constructor but
> > isn't, because it wasn't marked with @implicit (just like you
> > can right now). If code breakage were not a concern, then
> > there's pretty much no way that @implicit would be part of the
> > DIP. Personally, I don't think that the risk of breakage is
> > high enough for it to be worth requiring an attribute for what
> > should be the normal behavior (especially when such a
> > constructor almost certainly was intended to act like a copy
> > constructor, albeit an explicit one), but Andrei doesn't agree.
>
> The bog-standard way of dealing with avoidable breakage with DIPs
> is a -dip-10xx flag. In this case, if set, would prefer to call
> copy constructors over blit + postblit.
>
> Also adding @implicit is a backwards incompatible change to a
> codebase that wants to use it as it will cause it to fail on
> older compilers.  Even if one does :
>
> static if (__VERSION__ < 2085) // or whenever it gets implemented
>       enum implicit;
> all over the place,

I don't disagree, but it's not my decision.

- Jonathan M Davis