Getting action on your favorite D issues

[Avrina]

On Saturday, 6 June 2020 at 20:20:54 UTC, ag0aep6g wrote:
> 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.

g is defined behavior, or it wouldn't work. The result may not be 
known, but it is defined. Otherwise, what, a compiler could just 
insert anything they want there. An assert(0) that terminates the 
application.

The issue isn't with void initializers. It is whether a bool 
should be treated as a byte or single bit. Void initialization 
just leads to the problem, there's many ways it can be expressed. 
Someone else has shown it with unions. You can also just use 
casts as well and you'll get the same problem.

     bool e() { int x = 2; return *cast(bool*)&x; }

The issue with void initializers is that they aren't actually 
@safe, just as I can't use cast's in @safe code, I shouldn't be 
allowed to use void initializers in @safe.

Aside from that, it is still a problem because DMD's backend 
isn't consistent. Is bool a byte or a 1-bit integer. The decision 
has to be made and the backend fixed. The only thing in the spec 
I can find is that bool is a byte.

>>> 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.

No one is going to waste their time with that.

> [...]
>>> 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".

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.

Like I said, the Spec doesn't follow what is actually 
implemented. If you are to say that, then I would say, it is 
defined behavior unless the DMD or LDC implementation changes in 
such as way that makes it undefined behavior. It is the spec that 
differs, it doesn't match the implementation. Hell even that pull 
request wouldn't accurately make it match what the implementation 
does.