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
