Union redux

[Walter Bright via Digitalmars-d]

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.