Copy Constructor DIP and implementation

[Jonathan M Davis]

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.

> If at some point in the future we decide that we do want to add
> @implicit construction, then we can make the copy constructor
> always @implicit. Until that point I see no need for this,
> because it is replacing postblit which is always called
> implicitly.

Except that the whole reason that @implicit is being added is to avoid the
risk of breaking code, and that problem really isn't going to go away. So,
it's hard to see how we would ever be able to remove it. Certainly, if we
were willing to take the risks associated with it, there wouldn't be any
reason to introduce @implicit in the first place (at least not for copy
constructors).

If it were my decision, I wouldn't introduce @implicit and would risk the
code breakage (which I would expect to be pretty much non-existent much as
it theoretically could happen), but it's not my decision.

- Jonathan M Davis