Union redux

[deadalnix via Digitalmars-d]

On Tuesday, 2 June 2015 at 02:32:55 UTC, Andrei Alexandrescu 
wrote:
> On 6/1/15 7:18 PM, deadalnix wrote:
>> On Tuesday, 2 June 2015 at 00:11:09 UTC, Andrei Alexandrescu 
>> wrote:
>>> On 6/1/15 3:43 PM, deadalnix wrote:
>>>> On Monday, 1 June 2015 at 19:43:33 UTC, Andrei Alexandrescu 
>>>> wrote:
>>>>> 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.
>>>>>
>>>>
>>>> This is implied in C++ because of manual memory management. 
>>>> I don't
>>>> think it is in D.
>>>
>>> It is because destructors exist in both languages.
>>>
>>
>> It is common in D to have a struct with a constructor and no 
>> destructor.
>
> Probably there's a misunderstanding then. I'm saying the right 
> way to go is unions have no destructors at all.
>

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.

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.

>>>>>> 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.
>>>>>
>>>>
>>>> Without knowing the rationale in C++, it is difficult to 
>>>> assert that
>>>> this is also valid in D. You seems to be knowledgeable of 
>>>> the subject,
>>>> so surely you can enlight us on that one.
>>>
>>> I intentionally gave enough information to allow easy further
>>> research. http://goo.gl/19Nol5 lists N2412 and N2248 as top 
>>> hits,
>>> their motivation sections are relevant.
>>>
>>
>> The abstract of the 2 above mentioned link only discuss the
>> *constructor* case. It was never question of struct with 
>> constructor not
>> being able to be in union.
>
> 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.

Right now I'm not getting any of it, and instead I'm getting 
confrontation. That is not productive.

>> You attitude is only weakening your point.
>
> I'm not making a point. There is no debate. You said you want 
> to work on unions, that would be great. But this is a cut and 
> dried area. There's no room for creativity here. If you want to 
> be creative and design new programming language facilities, do 
> something else. For unions do what needs be done.
>

That is dishonest. First because there is almost no spec - so 
there is much to debate, second because what you propose is 
different from what is describe in the little spec there is 
(literally, no postblit/destructor in the union or its elements 
is the only that is specified).

Please stop projecting. You are the one being creative here.