Union redux

[Andrei Alexandrescu via Digitalmars-d]

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