Copy Constructor DIP and implementation

[Nicholas Wilson]

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,

> It is illegal to declare a copy constructor for a struct that 
> has a postblit defined and vice versa: