Getting action on your favorite D issues

Avrina avrina12309412342 at gmail.com
Sun Jun 7 19:01:39 UTC 2020


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.

Right C++ is more linate with undefined behavior, and it doesn't 
even have the rule that D does. 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.







More information about the Digitalmars-d mailing list