On Tuesday, 2 June 2015 at 05:07:43 UTC, Andrei Alexandrescu
wrote:
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 unfortunate that the explanation do not go over the
constructor but no desturctor case (way more common in D than in
C++). I think the case is not as strong for D, as a we already
allow struct with constructor, contrary to C++ when this document
was done. Still probably the right way forward, granted this is
@system. When you are in union land, you are pretty much on your
own anyway.
