On 6/1/15 12:00 PM, deadalnix wrote:
1/ .init for unions is not defined. I propose to define it as the .init
of the first field + padding with 0s if the union is larger than its
first member. It seems to be what is generated right now.
Fine.
2/ Default constructor takes one argument per union's field and assign
them all one over the other. This does not make any sense and need to be
changed. Proposed solutions :
a. Define one constructor for the first field.
b. Define N constructors, one per field.
c. Do not define constructors.
My preference goes for b, then a, then c, in that order.
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.
3/ union and @safe is currently undefined. I proposed to make everything
involving unions @system, and we will figure it out from there. At the
very least, all union with indirections and fields having a
posblit/destructor ust be @system.
A good first step. Let's.
4/ tupleof for unions generate a tuple will all field of the union. It
does not make much sense, and it is unclear if tupleof can make sense at
all on a union. Let's not have tupleof on union at all.
tupleof must generate a tuple recognizable by introspection engines. I
therefore thing tupleof with all members is the only approach that
doesn't lose information. Introspection engines can check is(X == union)
prior to interpreting tupleof.
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.
6/ struct with anonymous union in them define one parameter per union
field in the default constructor. This should probably lead to the same
solution as 2/
Structs can have auto-defined ctors only up to the union member.
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.
8/ unions and structs are mangled the same way (or so it seems). Bug or
feature ?
Not sure. Walter?
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.
10/ union that capture a closure are undefined. I think that right now,
they just add the context pointer at the same address as other fields,
which is nonsensical. Proposal :
a. Add the context at an address that do not overlap with other fields.
b. Do not allow union to capture a context.
No context please. We may add it later.
I'd say check the existing semantics, file bug reports, and make PRs for
a section on unions in the language reference that links to the issues
wherever the actual behavior is not in sync with the spec.
Andrei
