Union redux

[Andrei Alexandrescu via Digitalmars-d]

On 6/1/15 9:46 PM, deadalnix wrote:
> No, I asked you what is the rationale used to get types with
> postblit/destructor in unions (right now, the spec says no). I asked
> about the rationale for introduction of element with destructor/copy
> constructor in C++, but it turns out that the link provided also include
> constructor, and, in fact, only explore the constructor case in the
> rationale.

 From http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2248.html:

========
Unfortunately this brute-force approach cannot be extended to every 
user-defined type that a programmer might want to pass around 
transparently. As class types, unions are definitely second class: 
although a union may define a constructor and destructor for instances 
of its type, the standard does not allow it to contain any member whose 
default constructor, copy constructor, copy assignment operator, or 
destructor are non-trivial. The reason for these tight restrictions is 
obvious -- the compiler can hardly be expected to generate sensible 
default special member functions for an object whose type will only 
become known at run time, and therefore a "lowest-common-denominator" 
policy applies. With the rules in place, default initialization is 
effectively a no-op, likewise destruction, and copying is performed 
using a low-level memcpy.

This rules out the inclusion of "interesting" types, or else requires 
the programmer to ignore good design practice in order to make them 
conform to the straightjacket of trivial types (see discussion in N2172).

And yet the need for a "variant" data structure that can hold one object 
of a set of unrelated types is a problem that arises over and over [...]
========

There are others to be found in related docs. The simple explanation is 
that non-discriminated unions are most useful as unstructured bags that 
allow their users to plant their own types in whilst keeping their 
discriminant elsewhere. Planting either gratuitous restrictions on the 
storable data, or smarts regarding construction and destruction, simply 
reduces the range of things that unions are good at.

I don't know how to explain this better.

> It is important to consider why C++ did something to know if it makes
> sense to import it in D. I remind you that this is a change that you
> propose to the current state of affairs, meaning the burden of proof in
> on you.

Fair enough.

>> Then again sorry I am misunderstanding something. I'm saying the right
>> way to go is unions accept all types.
>>
>
> You are saying this. Many on that thread said otherwise. I personally
> have no strong opinion one way or another. That is why I'm asking about
> what makes you think element with postblit/destructor needs to be
> accepted in unions, in order to have all elements I needs to have an
> informed opinion.

The same explanation as above stands.


Andrei