copy-ctor's

[Manu]

On Mon, May 27, 2019 at 2:11 AM RazvanN via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> 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.

How soon? Is this another case of "just wait 10 more years before you
can use D"?
It looks like it needed to be fixed about 10 years ago, so no time
like the present! :)

> > 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.

Good idea, and easy to implement in minutes!
It's not a solution though, but it is one piece in a larger puzzle.

> 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.

This is useless, because if S does not have a copy constructor, the
object can't work under any circumstances.
It also wouldn't solve the problem, since the union item's destructor
is still called by the same rules, so copying is not the only issue
here.

> 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

Right, they shouldn't be mixed.
In this case, I could move forwards if the union issue was fixed though.
If T in the union did NOT call field-copy and field-destruction (which
is just a bug!), then I could static-check and manually handle the 2
cases of whether T has a copyctor or a postblit in the implementation
of the copy ctor of S, so I could reconcile the difference with some
extra work in S.

I think the only path to solution is to fix the issue with unions, and
that absolutely needs to happen anyway regardless.