On 15.06.19 02:46, Timon Gehr wrote:
> 
> 
>> You are just assuming how it was implemented to fit your argument, which is obviously biased. The code he posted used a static global, it would only make sense to also use a static global.
>> ...
> 
> Which I have considered, so your biased "obviously biased" accusation is obviously wrong. I will try to stop replying to your posts as they are anonymous, of poor quality and may actually be written in bad faith. (How likely is it that you would get essentially _every single thing_ horribly wrong?)

(I have set up a filter and will no longer receive your messages.)

On Friday, 14 June 2019 at 01:12:21 UTC, Timon Gehr wrote:
> On 14.06.19 02:23, Exil wrote:
>> On Thursday, 13 June 2019 at 21:26:37 UTC, Tim wrote:
>>> Here is a completly @safe version:
>>>
>>> import std.stdio;
>>>
>>> static int[2] data;
>>> static int[253] data2;
>>>
>>> void test(bool b) @safe
>>> {
>>>     data[b]++;
>>> }
>>>
>>> void main() @safe
>>> {
>>>     bool b = void;
>>>     writeln(data, data2);
>>>     test(b);
>>>     writeln(data, data2);
>>> }
>>>
>>> If b is valid only data can change. But for me data2 changes, even though it is never written to.
>> 
>> This is a bug.
>
> Yes. And the bug is either
> - that `void` initialization of `bool` is `@safe`.
> - that `void` initialization of `bool` can produce a value that is both `true` and `false`.
> - that boolean values are assumed to be either `true` or `false` in @safe code.

I'm not yet sure in the general case about void initialization, but for me this interesting case shows that:

- void initialization of bool should be illegal, not just in @safe code, anywhere. Initializing an int void works as (undefinedly) as intended, but with bool it breaks the spec;

- I never understood why D adopted over from C/C++ that bool is int and implicitly convertible; I don't understand when this may be useful.

On Thursday, 13 June 2019 at 21:26:37 UTC, Tim wrote:
> On Thursday, 13 June 2019 at 20:55:34 UTC, Exil wrote:
>> This problem happens because you are used @trusted. If you used @safe you wouldn't be able to increment pointers and modify the values the way you did in @trusted.
>
> Here is a completly @safe version:
>
> import std.stdio;
>
> static int[2] data;
> static int[253] data2;
>
> void test(bool b) @safe
> {
> 	data[b]++;
> }
>
> void main() @safe
> {
> 	bool b = void;
> 	writeln(data, data2);
> 	test(b);
> 	writeln(data, data2);	
> }
>
> If b is valid only data can change. But for me data2 changes, even though it is never written to.

I have created a bugzilla issue for this bug: https://issues.dlang.org/show_bug.cgi?id=19968

On 15.06.19 10:40, XavierAP wrote:
>>>
>>
>> Yes. And the bug is either
>> - that `void` initialization of `bool` is `@safe`.
>> - that `void` initialization of `bool` can produce a value that is both `true` and `false`.
>> - that boolean values are assumed to be either `true` or `false` in @safe code.
> 
> I'm not yet sure in the general case about void initialization, but for me this interesting case shows that:
> 
> - void initialization of bool should be illegal, not just in @safe code, anywhere. Initializing an int void works as (undefinedly) as intended, 

Accessing a `void`-initialized `int` may work with current compilers, but this is not guaranteed by the spec.

> but with bool it breaks the spec;
> ...

It does not break the spec:

"Undefined Behavior: If a void initialized variable's value is used before it is set, the behavior is undefined."

https://dlang.org/spec/declaration.html#void_init

Undefined means the behavior can be anything at all, including that the program behaves as if some bool was true and false at the same time. As soon as you trigger undefined behavior, you can't assume that the program that is executing is actually the program that you wrote.

> - I never understood why D adopted over from C/C++ that bool is int and implicitly convertible; I don't understand when this may be useful.

It can be useful, but it is not necessarily worth the savings (because (b?1:0) is so short).

One case where I sometimes use it is if I need four offsets to neighboring grid squares, then I just write:

int i,j; // position of current grid square
foreach(k;0..4){
    auto ni=i+(k==0)-(k==1);
    auto nj=j+(k==2)-(k==3);
    foo(ni,nj); // do something with neighbor
}

Without the feature, I could write

int i,j;
foreach(k;0..4){
    auto ni=i+(k==0?1:k==1?-1:0);
    auto nj=j+(k==2?1:k==3?-1:0);
    foo(ni,nj);
}

Another case where it may be useful is if you like to initialize your bools using literals `0` and `1`.

On Saturday, 15 June 2019 at 13:39:13 UTC, Timon Gehr wrote:
>
> It does not break the spec:
>
> "Undefined Behavior: If a void initialized variable's value is used before it is set, the behavior is undefined."
>
> https://dlang.org/spec/declaration.html#void_init

You're right about the spec... Still void initialization of bool should be illegal, in @safe code (as void init pointers and refs already is) or better yet in any case.

If you're going the squeeze route of void initializations, you'd better use ints, no point in a bool abstraction.

>> - I never understood why D adopted over from C/C++ that bool is int and implicitly convertible; I don't understand when this may be useful.
>
> It can be useful, but it is not necessarily worth the savings (because (b?1:0) is so short).

Plus you can write these as extension methods, as I used to do in C# (which makes a design point of allowing no casting, implicit nor explicit, either way between bool and int):

	bool tobool(T)(T i) { return i != 0; }
	int toint(bool b) { return b?1:0; }

> Another case where it may be useful is if you like to initialize your bools using literals `0` and `1`.

Implicit conversion from bool to int is much more dangerous than int to bool (plus people may really want if(int) for interop). And two-ways implicit cast is also inconsistent with

	static assert( is(bool:int) );
	static assert(!is(int:bool) );

The pitfalls of implicitness... Explicit implies readable.

On Saturday, 15 June 2019 at 08:40:52 UTC, XavierAP wrote:
> I'm not yet sure in the general case about void initialization, but for me this interesting case shows that:
>
> - void initialization of bool should be illegal, not just in @safe code, anywhere. Initializing an int void works as (undefinedly) as intended, but with bool it breaks the spec;

It's not just bool, it's also enums at the very least.

I suspect someone familiar enough with their compiler could find other ways to leak memory; eg by casting a `byte` to an `int` in such a way that the compiler loads 4 bytes of uninitialized memory, instead of 3 zero-ed bytes and 1 uninitialized byte, but still assumes the resulting int is less than 255.

Also, Rust apparently had the same problem for a while:
https://gankro.github.io/blah/initialize-me-maybe/

> - I never understood why D adopted over from C/C++ that bool is int and implicitly convertible; I don't understand when this may be useful.

It doesn't really matter, the problem still occurs if you do an explicit cast.

The problem is that uninitialized memory lets the compiler make assumptions that aren't always true. Bounds checking is the easiest to demonstrate, but you can probably find other applications if you dig a little.

On Tuesday, 18 June 2019 at 18:08:31 UTC, Olivier FAURE wrote:
>
> It's not just bool, it's also enums at the very least.
> [...]
> It doesn't really matter, the problem still occurs if you do an explicit cast.

I understand, I meant that there is an additional difference of intent when using a bool or enum, or an integer explicitly. Declaring variables as bool or enums, even though these types are under the hood implemented as integers, makes the code appear more type-safe than declaring them as int (even if still using or casting them as bool or enum). But the type-safety of bool and enums is actually broken. My meaning was, do you need these fancy sugar types if you are writing =void C/asm-like code, hadn't you better use int only in these cases?

Anyway in general, void initialization is already not @safe in case of pointers, classes or interfaces. Perhaps it has to be moved out of @safe completely. It's not as drastic as eliminating it completely.