Getting action on your favorite D issues

[Timon Gehr]

On 07.06.20 21:01, Avrina wrote:
> On Sunday, 7 June 2020 at 14:55:07 UTC, ag0aep6g wrote:
>> On Sunday, 7 June 2020 at 13:10:22 UTC, Avrina wrote:
>>> It's not though. There is expected behavior for void initializers. 
>>> Otherwise what you are saying is that C++ has undefined behavior for 
>>> using variables that aren't initialized (which are all of them unless 
>>> they are initialized first). But it doesn't. The behavior is 
>>> expected. The root of the problem isn't with void initialization 
>>> because the behavior is defined. The problem is with the boolean type 
>>> and the loose definition the spec provides it. Boolean is undefined 
>>> behavior in D, as long as the implementation in DMD and LDC differ, 
>>> and there's nothing in the spec to define it.
>>
>> The spec clearly says that using an uninitialized value has undefined 
>> behavior. That doesn't go away just because you don't like it, or 
>> because C++ doesn't have that rule.
> 
> I think we agree on about everything else.
> 
> The spec is wrong/incorrect/incomplete in a lot of places, as you agree. 
> This is just another one. There's nothing an implementation can do that 
> would reasonably make sense for it undefined behavior, unlike with 
> something like little/big endian and unions or bit fields in C++. 
> Reading a void initialized variable is no different than reading a 
> randomized variable.
> ...

It is not so simple, as the case with bool demonstrates.

> Right C++ is more linate with undefined behavior, and it doesn't even 
> have the rule that D does.

Reading a trap representation is UB in C++, so reading an uninitialized 
bool in C++ will cause UB.

> Reading uninitialized memory doesn't change 
> or have any reason to change under any circumstances. It has no reason 
> to be undefined behavior and is a mistake in the specs part.
> 

It's not a mistake, there is also no reason why it can't be UB. The 
mistake is that it is UB and allowed in @safe code at the same time.