Getting action on your favorite D issues

[ag0aep6g]

On Saturday, 6 June 2020 at 18:30:15 UTC, Avrina wrote:
> On Saturday, 6 June 2020 at 15:16:06 UTC, ag0aep6g wrote:
[...]
> So your saying void initializers don't have a defined function 
> then? So if LDC wants it could initialise the memory.of all 
> void initialized variables to zero and that would be considered 
> within defined behaviour? If void initializers are undefined 
> behaviour then the feature is useless.

It's not void initializers themselves that have undefined 
behavior. Using an uninitialized value has undefined behavior. In 
code:

----
int f() { int x = void; x = 42; return x + 1; } /* This is fine. 
*/
int g() { int x = void; return x + 1; } /* This is not. */
----

If LDC defines behavior for `g`, it creates a dialect of D which 
has less undefined behavior than (current) standard D.

>> But the spec doesn't do that. Instead it says: "If a void 
>> initialized variable's value is used before it is set, the 
>> behavior is undefined." That is, the spec explicitly says that 
>> doing so is not allowed, and that compilers may assume that it 
>> doesn't happen. Because that's what "undefined behavior" means.
>
> The spec is poorly written. The language doesn't do what's 
> written in it for a lot of cases on top of that.

True. Which is why a lot of fixing needs to be done. Sometimes 
the spec needs to be changed, sometimes the implementation, 
sometimes both.

[...]
>> But Walter agrees with you: Using a void value shouldn't 
>> actually have undefined behavior; it should just be an 
>> arbitrary value. Which is why he has an open pull request to 
>> change the spec:
>> https://github.com/dlang/dlang.org/pull/2260
>
> Yea and that pull request is years old. If that change does go 
> into effect then the spec will reflect the actual reality of 
> what is happening.

Sure. But as long as the PR is in limbo, Patrick Schluter has a 
point when he says that "undefined behaviour is undefined 
behaviour".