On Monday, 1 June 2015 at 19:43:33 UTC, Andrei Alexandrescu wrote:
Do not define constructors. They ostensibly imply commitment to
remembering to call the appropriate destructor. A union can
only be default constructed (with its init value as described)
and has no destructor.
This is implied in C++ because of manual memory management. I
don't think it is in D.
5/ union currently disallow members with postblit and/or
destructor . It
seems that this was needed in C++ as per Andrei's comments. It
seems to
me that, because of manual memory management, C++ would have a
lot more
struct with copy constructor and/or destructor than in D, so
I'm not
sure if this require change in spec. Andrei, can you give more
details
on the C++ situation here ?
That rule has hurt C++ everywhere, and the community credits
Lois Goldthwaite for pushing the current rule, which allows
types with cdtors in unions. Let's go the same way, unions are
all but useless otherwise.
Without knowing the rationale in C++, it is difficult to assert
that this is also valid in D. You seems to be knowledgeable of
the subject, so surely you can enlight us on that one.
7/ struct with anonymous union in them have one entry per
union field in
their tupleof. All the union field should be present as one
entry in the
tupleof, with a compiler generated union type.
Again the litmus test here is enabling introspection. Structs
with anonymous union members should have one member called e.g.
__anonymous__ in their tupleof, and in turn introspecting that
member should list its tuple.
Compiler generated tuples are auto flattening in D. That would
not work unless the entry in the struct tuple is an (compiler
generated) union.
9/ union alignement is not specified. union align should be
least common
multiple of union's fields.
Yes. Since they're all powers of 2, taking the max is the same
thing. BTW, to my surprise on OSX real.alignof is 16, but the
alignof a union containing a real is 8. I think that's a bug.
Please verify and file.
Indeed, max is the same thing, but because of plateform specific
characteristics. I don't think we should rely on them unless we
need to (implementation can still use max).
