On Friday, 5 June 2020 at 20:35:57 UTC, Walter Bright wrote:
> If you've got problems using D that should be fixed:
>
> 1. File bugzilla issue for them. Issues not in bugzilla don't get fixed.
>
> 2. When talking about the issue, provide a link to the bugzilla issue so we know what you're talking about and know what the current status is.
>
> 3. If you have a laundry list of issues that are important to you, keep a list of bugzilla issue links to them. Then, when you are asked about what problems you're having, cut&paste that list.
>
> Bring them up now and then.
>
> It's that simple!

I'd also say just make it a habit of filing bugs! It's really important to file bugs even if one thinks they're the only one that could be affected by the bug. Even if a bug doesn't get a response in a long time it does not mean it's ignored!

I've filed 697 bugs on Bugzilla so far. And while on first glance it might seem like "wow, D sure has a lot of bugs!", I don't feel about it that way. If you use this language for over a decade you are sure to find some implementation bugs here and there. And there is no goalpost where one could say "*this* is a reasonable amount of open bugs a project should have".

If D's user base suddenly grew 10x over night we would have a lot more bugs filed. But that's a good thing because it means those bugs were always there, they were just undiscovered or not filed.

On Saturday, 6 June 2020 at 15:46:10 UTC, Andrej Mitrovic wrote:
> I've filed 697 bugs on Bugzilla so far.

And one tiny correction here, I meant issues, not bugs. Most were bugs, but some were enhancements and others were invalid bugs too. Anyway tl;dr: file bugs!

On 6/6/20 9:31 AM, Meta wrote:
> On Saturday, 6 June 2020 at 03:56:43 UTC, Timon Gehr wrote:
>> On 06.06.20 05:40, Meta wrote:
>>>
>>> The linked defect, and the issue you posted, don't really make sense to me. They both have UB; reading from an uninitialized variable (= void), or writing to one member of a union and reading from the other. Invoke Undefined Behaviour and you get... Undefined Behaviour.
>>
>> Right. It's in @safe code.
> 
> Ah, yes, I missed that. Why the hell is = void allowed in @safe again? I vaguely remember Walter arguing that it should be for some reason.

int x = void;

Does not and cannot corrupt memory (assuming everything that uses it is @safe).

The larger issue here is that bool is really an integer type from 0 to 1, but is implemented as an 8-bit value. In that case, the assumptions made by the compiler are not always correct.

There was a DIP to make bool actually not an integer, and it was rejected.

-Steve

On Saturday, 6 June 2020 at 00:01:46 UTC, mw wrote:
> Actually I'm wondering if we can have a web poll widget somewhere, so people can vote on the priority of bugs / features / DIPs?

I'm not sure if voting is necessarily the best way to prioritize, although it probably is important to have some way to track how many people are affected by a given issue.

On Saturday, 6 June 2020 at 13:30:53 UTC, Seb wrote:
> On Saturday, 6 June 2020 at 13:08:06 UTC, ag0aep6g wrote:
>> On 06.06.20 04:41, Walter Bright wrote:
>>> You can already vote on Bugzilla issues.
>>
>> No you can't. The feature was disabled or removed at some point.
>
> Yeah, though hopefully with the in-progress migration to GitHub issues voting will soon be possible again, see e.g. https://github.com/dlang/tools/issues/411

So should issues continue to be filed in bugzilla? Why not move new issues to GitHub directly?

On Saturday, 6 June 2020 at 16:48:56 UTC, Steven Schveighoffer wrote:
> int x = void;
>
> Does not and cannot corrupt memory (assuming everything that uses it is @safe).

Yes, which is presumably why the other example above -- using the wrong accessor of a union -- is also allowed in @safe code ... ?

That said, the definition of a safe interface is, according to spec, that it exhibits no undefined behaviour:
https://dlang.org/spec/function.html#safe-interfaces

Don't using void-initialized variables or the wrong accessors of a union both count as undefined behaviour, even if they are memory-safe?

On Saturday, 6 June 2020, at 00:25:15 UTC, H. S. Teoh wrote:
> [... snip ...]
> OK, I'll stop now. :-P
>
>
> T

Sorry, but I have another one. The point in Schrödinger's matter is not to formulate a state, which does not exist. On observation, the cat is either dead or alive. With the current D behavior, the state of the cat is more like in The Walking Dead.

´´´
auto schrodingersCat() @safe {
    union Box { bool b; int spin; }
    Box u;
    u.spin = 2;
    return u.b;
}
void main() @safe {	
    import std.stdio : writeln;
    const b = schrodingersCat();
    if(b & !b){
        writeln("doomed");
    } else {
        if (b) writeln("alive");
	if (!b) writeln("dead");
    }
}
´´´

On Saturday, 6 June 2020 at 15:36:07 UTC, Patrick Schluter wrote:
> On Saturday, 6 June 2020 at 14:34:11 UTC, Avrina wrote:
>> On Saturday, 6 June 2020 at 10:09:07 UTC, Patrick Schluter wrote:
>>> On Friday, 5 June 2020 at 23:53:28 UTC, H. S. Teoh wrote:
>>>> Output:
>>>> -----------------
>>>> dead
>>>> -----------------
>>>>
>>>> Truly, DMD's backend is in the bright future of strange and wonderful quantum effects, whereas LDC is clearly still stuck in the antiquated classical past. ;-)
>>>>
>>> Sorry, but undefined behaviour is undefined behaviour. The dmd code generator is not at fault here.
>>
>> With statements like this I always feel like people don't understand what "undefined behavior" means.
>>
>> All the void initializer does is not initialize the memory of the bool. DMD is testing more than a single bit for a type that is only a single bit, it flip flops between testing a byte and testing a bit. That is most definitely a bug in the DMD backend.
>
> Then it is also a bug in llvm and gcc as they generate the code under exactly the same assumption that a bool is 1 or 0 (and that in C, C++ and D).
> Only in contexts where there is int promotion is all the word checked.

No, that's why LDC doesn't have the same issue. D is suppose to be better than C and C++, so saying its broken in C and C++ so D should be broken too isn't a very convincing argument.

The issue is that DMD isn't consistent. Like I said before, it flip flops between checking a single bit and 8 bits.


> This has nothing to do with the D frontend, #pure or whatnot. It's a pure backend code generation assumption.
> If the frontend violates that assumption, it is an issue of the frontend.

Which is why I said its an issue with the backend.

>>
>> Just to bring up an old debate, this has been argued to not be a bug and is defined behavior and *will not* be changed.
>>
>>   void foo(bool);
>>   void foo(byte);
>>
>>   foo(0); // calls bool
>>   foo(1); // calls bool
>>   foo(2); // calls byte
>
> This has nothing to do with the issue at hand.
> This it's a technical choice. It might be surprising, it is very likely a wrong choice, but it is not violation of the assumption of the backend (even if it a violation of the programmer).

I know it doesn't. The point was that book is treated as a 1-bit integer, and DMDs backend treats it like a byte (sometimes).

On Saturday, 6 June 2020 at 15:16:06 UTC, ag0aep6g wrote:
> On 06.06.20 16:34, Avrina wrote:
>> On Saturday, 6 June 2020 at 10:09:07 UTC, Patrick Schluter wrote:
> [...]
>>> Sorry, but undefined behaviour is undefined behaviour. The dmd code generator is not at fault here.
>> 
>> With statements like this I always feel like people don't understand what "undefined behavior" means.
>
> I'm not so sure if you really understand what "undefined behavior" means.
>
> By saying this:
>
>> All the void initializer does is not initialize the memory of the bool.
>
> you're defining the behavior of using void initialized values. Once you do that, it's not undefined behavior anymore.

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.

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

It just means the compiler can choose to implement it in any way it wants. DMD chooses to treat a boolean as both a 1-bit integer and an 8-bit integer. That isn't consistent with its own implementation. There's no reason for it to to be consistent.

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

On Saturday, 6 June 2020 at 14:02:54 UTC, ag0aep6g wrote:
>
> I had thought about special-casing bool there, precisely because of the issue at hand. I almost wrote that only 0 and 1 are safe values for bool.
>
> I decided against it, because it seems unlikely that creating values beyond 1 will be banned in @safe code. It seems more likely that the implementation gets changed to treat all non-zero values as true. At least that's what I extrapolate from Walter's position on void initialization in general (see <https://github.com/dlang/dlang.org/pull/2260/files>).

It seems to me like (a) whether void initialization results in undefined behavior or merely unspecified values, and (b) whether bool values other than 0 and 1 are considered valid are independent questions. That is, it would be perfectly consistent to say that void initialization of int in @safe code is fine, because every 4-byte bit pattern represents a valid int, but void-initialization of bool in @safe code is no good, because many 1-byte bit patterns do not represent valid bools.