On Sunday, June 9, 2019 3:27:39 AM MDT KnightMare via Digitalmars-d wrote:
> On Sunday, 9 June 2019 at 08:36:30 UTC, Patrick Schluter wrote:
>
> I read the bible too. I know reasons why leaders decided use NaN
> and FF.
> but
> what is the best solution:
> do some math and get garbage in C++ or NaN in D?
> or compiler will tell "using unitialized variable" before any
> math?

Given how init works in D and how it's used all over the place, it really isn't feasible to have the compiler tell you to initialize the variable. A prime example would be with dynamic arrays. Mutating the length of a dynamic array has to use the init value. e.g.

arr.length += 15;

wouldn't work if init weren't used. Another example would be out parameters. They get assigned the init value for the type when the function is called.

A lot of aspects of D are built around the fact that every type has an init value and the fact that values of that type are always initialized to that init value if they're not given an explicit value. At some point during the language's development, the ability to @disable the default intialization of a type was added, but even those types still have an init value. And while it works, @disabling default initialization causes all kinds of subtle problems precisely because D was built around the idea that every type could be default-initialized.

Sure, there are some downsides to D's approach (such as getting unexpected NaNs or not having default constructors for structs), but it also solves a whole class of problems that other languages like C and C++ have with garbage values. Even Java has problems with garbage values in spite of it requiring that you initialize variables before using them (e.g. it's quite possible to use a static variable in Java before it's initialized because of circular reference issues). D, on the other hand, never has garbage values unless you use @system features like = void to force it.

- Jonathan M Davis

On 6/9/19 8:19 AM, Ola Fosheim Grøstad wrote:
> On Sunday, 9 June 2019 at 08:36:30 UTC, Patrick Schluter wrote:
>> No, by putting NaN in d you hav e a deterministic error. In C and C++ you will have undefined behaviour that will vary with compiler, version, options, OS version, architecture, position of the moon, etc. and sometimes undetectable bugs.
> 
> I don't think it is undefined though… If something has an arbitrary value, you could still compute with it, if the algorithm takes that into account. Assuming that all bit-patterns provides a defined value (which is the case for IEEE floating point bit-patterns).
> 
> Anyway, the obvious advantage with having structs default initialized to all-bits-zero is that you can have an allocator that clears bits in the background (bypassing caches so they are not polluted).
> 
> Then you have no penalty when allocating an array of one million struct values. Which is very useful. Just allocate memory-chunks that are already set to zero-bits.
> 
> You usually want an array of floating point values to be pre-initialized to zeros. You almost never want an array of floating point values being initialized to NaN.
> 


Yes, and further I would suggest that non-zero-bit initializations violate the principle of least surprise.

As someone posted upthread, it would be interesting to take a poll of new users (or non users, or perhaps the D-curious) and ask what their best guess is for each default value.

On Sunday, 9 June 2019 at 12:19:43 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 9 June 2019 at 08:36:30 UTC, Patrick Schluter wrote:
>> No, by putting NaN in d you hav e a deterministic error. In C and C++ you will have undefined behaviour that will vary with compiler, version, options, OS version, architecture, position of the moon, etc. and sometimes undetectable bugs.
>
> I don't think it is undefined though…

It is undefined behaviour by the definition of the standard. undefined behaviour includes behaviour that can be explained.

On Sunday, 9 June 2019 at 18:27:07 UTC, Patrick Schluter wrote:
> On Sunday, 9 June 2019 at 12:19:43 UTC, Ola Fosheim Grøstad wrote:
>> On Sunday, 9 June 2019 at 08:36:30 UTC, Patrick Schluter wrote:
>>> No, by putting NaN in d you hav e a deterministic error. In C and C++ you will have undefined behaviour that will vary with compiler, version, options, OS version, architecture, position of the moon, etc. and sometimes undetectable bugs.
>>
>> I don't think it is undefined though…
>
> It is undefined behaviour by the definition of the standard. undefined behaviour includes behaviour that can be explained.

To be fair, the C standard (C11) is a bit self-contradicting there. Variables of automatic storage duration that are not explicitly initialized contain an unspecified value (i. e. any valid value) or a trap representation. Types such as integers usually don't have any trap representations so reading them should be defined on most platforms (unless C permits some sort of compile-time-only trap representation? not sure.). Then there's informative(!) annex J which explicitly lists it as undefined behavior.

On Sunday, 9 June 2019 at 13:45:07 UTC, Jonathan M Davis wrote:
> Mutating the length of a dynamic array has to use the init value. e.g.
> arr.length += 15;
> wouldn't work if init weren't used.

this mean that u should initialize added elements to some value(usual 0.0) again, coz NaN is not useful at all, no any case where u can use it. tada! double work!

> A lot of aspects of D are built around the fact that every type has an init value and the fact that values of that type are always initialized to that init value if they're not given an explicit value.
I agree that data will should be initialized.. but with "all zeroes" not NaN or \xFF.

> @disable..
I found only this https://dlang.org/spec/attribute.html#disable
I feel that I miss something. what is your point?

> not having default constructors for structs
I am accepting it, its only in my responsibility assign some values to fields. but "all fields are zeroes" is good choice for me.
NaN - means that I should to think small details when I switch from C# (in my case) to D. in other words I unexpect NaN when I do nothing.