copy-ctor's

[RazvanN]

On Saturday, 25 May 2019 at 23:15:05 UTC, Manu wrote:
> So, it seems that if an object has a postblit and a copy 
> constructor, the postblit is preferred.
>
> It also seems that if an object has a copy constructor and a 
> MEMBER with a postblit, then object has a postblit generated 
> which calls through to the member, and that is preferred.
>
> I have also noticed that if you have a union containing an item 
> with a postblit, the postblit is always called, even if the 
> item in the union is not valid:
>
That's a bug, but I think that it's not going to be fixed since 
the postblit
should be deprecated soon.

> struct S(T)
> {
>   union {
>     int x = 0;
>     T y = void;
>   }
>   bool isT = false;
> }
>
> S a;
> S b = a; // calls `y's postblit, even though it's `isT` is 
> false and
> the object is `void` initialised...
>
> So, it's very hard to craft a tool like 'S', when the supplied 
> T might have a postblit and ruin everything. What are my 
> options here?
>
Currently, you don't have any options. As I see it, there are 3 
possible solutions:

1. Change the semantics of `disable this(this)` from "object is 
not copyable"
to "object is not copyable through postblit". This way we can 
exclude postblits
but allow copies using the copy constructor.

2. Check if T has postblit with a static if (via traits) and 
define the copy
constructor only if T does not have a postblit.

3. Issue a deprecation if T has a postblit.

Essentially, there is no clear way in how you can mix object with 
postblits and objects with copy constructor

> Also, `hasElaborateCopyConstructor` is broken now. It should 
> know about copy ctor's.