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:

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?

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

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:
>
> 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?
>
> Also, `hasElaborateCopyConstructor` is broken now. It should know about copy ctor's.

Seems a union also calls the postblit for every object in a union, which makes less sense, since only one of them should be valid at a time.

IIRC there was also a problem with copy constructors conflicting with the default constructor initalizers. Would probably be best to iron out all these bugs now before it gets used too much.

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.

Correct, that is the transitional behaviour until postblit is truly dead.

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

Thats probably a bit of a grey area. I'll defer to Razvan for that one.

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

Thats a bug.

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

File a bug report and ensure that Razvan Nitu is CC'd.

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

https://run.dlang.io/gist/71e722a80b5a9ab54625508915bc7738?compiler=dmd-beta _almost_ does it, I'm not quite sure what I'm missing though.

On Sat, May 25, 2019 at 9:15 PM Nicholas Wilson via Digitalmars-d <digitalmars-d@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.
>
> Correct, that is the transitional behaviour until postblit is truly dead.

Right, but it's not a helpful behaviour; it undermines copy ctors... in my example above, 'S' can't control the template argument, which means `T` may have a postblit and so `S` can't possibly be written to work.

> > 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:
>
> Thats a bug.

Indeed.

I also noticed another one; it doesn't just call postblit's for each
item in the union, it also calls destructors for each item in the
union! O_O
How has this issue never come up?

> > 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?
>
> File a bug report and ensure that Razvan Nitu is CC'd.

I don't know his email address... that CC box seems to work by email addresses.

On Sunday, 26 May 2019 at 20:38:48 UTC, Manu wrote:
> item in the union, it also calls destructors for each item in the
> union! O_O
> How has this issue never come up?

It has, since 2010?

https://forum.dlang.org/search?q=union%20destructors

Haha, and I'm the OP... not surprised at all ;)

On Sun, May 26, 2019 at 2:40 PM Ola Fosheim Grøstad via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 26 May 2019 at 20:38:48 UTC, Manu wrote:
> > item in the union, it also calls destructors for each item in
> > the
> > union! O_O
> > How has this issue never come up?
>
> It has, since 2010?
>
> https://forum.dlang.org/search?q=union%20destructors
>

Oh, no.. that's search results, listed recent first. I didn't realise the forum could do that.

On Sun, May 26, 2019 at 3:32 PM Manu <turkeyman@gmail.com> wrote:
>
> Haha, and I'm the OP... not surprised at all ;)
>
> On Sun, May 26, 2019 at 2:40 PM Ola Fosheim Grøstad via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On Sunday, 26 May 2019 at 20:38:48 UTC, Manu wrote:
> > > item in the union, it also calls destructors for each item in
> > > the
> > > union! O_O
> > > How has this issue never come up?
> >
> > It has, since 2010?
> >
> > https://forum.dlang.org/search?q=union%20destructors
> >

On Sunday, 26 May 2019 at 22:33:48 UTC, Manu wrote:
> Oh, no.. that's search results, listed recent first. I didn't realise the forum could do that.

Oh yes, that can be confusing.

Untagged unions doesn't really play well with destructors in any language. I think C++ requires that those destructors are ignored and that the union's destructor should do the cleanup. Seems like a thing that is easy to forget though…

On Sunday, 26 May 2019 at 23:45:05 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 26 May 2019 at 22:33:48 UTC, Manu wrote:
>> Oh, no.. that's search results, listed recent first. I didn't realise the forum could do that.
>
> Oh yes, that can be confusing.
>
> Untagged unions doesn't really play well with destructors in any language. I think C++ requires that those destructors are ignored and that the union's destructor should do the cleanup. Seems like a thing that is easy to forget though…

I vaguely remember Bearophile suggest that the union/struct should provide a means to identify which type the union was holding.

One usually has a union in a struct that also contains a tag of some sort that signifies the type of the union… but I think this is outside the scope of D as a language.

So perhaps one should not be allowed to have destructors in untagged unions and encourage the use of tagged unions…

On Sun, May 26, 2019 at 4:55 PM Ola Fosheim Grøstad via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 26 May 2019 at 23:45:05 UTC, Ola Fosheim Grøstad wrote:
> > On Sunday, 26 May 2019 at 22:33:48 UTC, Manu wrote:
> >> Oh, no.. that's search results, listed recent first. I didn't realise the forum could do that.
> >
> > Oh yes, that can be confusing.
> >
> > Untagged unions doesn't really play well with destructors in any language. I think C++ requires that those destructors are ignored and that the union's destructor should do the cleanup. Seems like a thing that is easy to forget though…
>
> I vaguely remember Bearophile suggest that the union/struct should provide a means to identify which type the union was holding.
>
> One usually has a union in a struct that also contains a tag of some sort that signifies the type of the union… but I think this is outside the scope of D as a language.
>
> So perhaps one should not be allowed to have destructors in untagged unions and encourage the use of tagged unions…

Well I'm obviously implementing a tagged union.
The language just needs to make the feature available, and let me wrap it up.
The proper thing to do here, is disable field-copy/destruction for
items in unions, and if the owning type doesn't declare
copy-ctor/destructors, then the default functions should be @disabled
rather than generated from fields as usual.
It should also be un-@safe to reference a member of a union from any
method, and from there we have everything we need to write tooling.