On 6/1/2015 12:43 PM, Andrei Alexandrescu wrote:
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.
"Fine" as in "yes" :-)
For non-native speakers, the use of "fine" is often confusing. "Fine" in
American english means "you're wrong, but I won't argue the point." It does not
signify endorsement.
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.
Yes. Option (c). (We can always relax this later, but undoing (a) or (b) may be
impossible.)
3/ union and @safe is currently undefined. I proposed to make everything
involving unions @system, and we will figure it out from there.
No.
At the
very least, all union with indirections and fields having a
posblit/destructor ust be @system.
Yes.
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.
Yes.
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.
I defer to Andrei's expertise here.
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.
Yes.
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.
Sounds good.
8/ unions and structs are mangled the same way (or so it seems). Bug or
feature ?
Not sure. Walter?
I think it's fine.
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.
Union alignment must be the largest alignment of any of its fields. The same as
for structs.
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.
Yes. Option (b) - issue an error if it is attempted.
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.
Yes.
