Search
```On 8/21/22 20:28, claptrap wrote:
> On Sunday, 21 August 2022 at 16:51:51 UTC, Walter Bright wrote:
>> Consider the following pattern, which doesn't appear
>>
>>
>> 1. x is default initialized to NaN. bar(x) produces a NaN result on everything dependent on x. User knows there's a problem.
>>
>> 2. x is default initialized to 0. bar(0) may exhibit problems, but these problems won't necessarily be noticed.
>
> This is the problem, you suggest that if a variable is zero initialised in error the problems it causes "wont necessarily" be noticed.
>
> I'm saying that's not true, I'm saying it will almost always be noticed.
>
>
>

It will be noticed but what price? You've initialized all vars to 0 so how do you know that this exactly initialization to zero is wrong? To detect it you should track down manually checking the intermediate results that is manually calculate results and compare to what you get. It takes much more time than checking if the value is NaN.
```
```On Sunday, 21 August 2022 at 17:56:58 UTC, drug007 wrote:
> On 8/21/22 20:28, claptrap wrote:
>> On Sunday, 21 August 2022 at 16:51:51 UTC, Walter Bright wrote:
>>> Consider the following pattern, which doesn't appear
>>>
>>>
>>> 1. x is default initialized to NaN. bar(x) produces a NaN result on everything dependent on x. User knows there's a problem.
>>>
>>> 2. x is default initialized to 0. bar(0) may exhibit problems, but these problems won't necessarily be noticed.
>>
>> This is the problem, you suggest that if a variable is zero initialised in error the problems it causes "wont necessarily" be noticed.
>>
>> I'm saying that's not true, I'm saying it will almost always be noticed.
>>
>>
>>
>
> It will be noticed but what price? You've initialized all vars to 0 so how do you know that this exactly initialization to zero is wrong? To detect it you should track down manually checking the intermediate results that is manually calculate results and compare to what you get. It takes much more time than checking if the value is NaN.

Price for this float=NaN & char=FF
1. Runtime bloat -> all struct/class with (float or char) need special initializer
2. Slow -> all struct/class not able to utilize zero initialized from memory manager
3. Inconsistent with other value types (all zero bits)

So -> Better error when var is not initialized than this special value

```
```On Sunday, 21 August 2022 at 19:57:52 UTC, apz28 wrote:
>
> Price for this float=NaN & char=FF
> 1. Runtime bloat -> all struct/class with (float or char) need special initializer
> 2. Slow -> all struct/class not able to utilize zero initialized from memory manager
> 3. Inconsistent with other value types (all zero bits)
>
> So -> Better error when var is not initialized than this special value

These are very good points which I agree with. Previously I was a bit it didn't matter for me (either Nan or 0.0) but with these my mind tipped over in favor of zero for both char and floats. It is a better design because of the consistency as well it enables the optimizer to use large moves in order to initialize the memory. However, will it be the real use case after optimizing away unused values, that is the question.
```
```On 8/21/22 22:57, apz28 wrote:
>>
>> It will be noticed but what price? You've initialized all vars to 0 so how do you know that this exactly initialization to zero is wrong? To detect it you should track down manually checking the intermediate results that is manually calculate results and compare to what you get. It takes much more time than checking if the value is NaN.
>
> Price for this float=NaN & char=FF
> 1. Runtime bloat -> all struct/class with (float or char) need special initializer
> 2. Slow -> all struct/class not able to utilize zero initialized from memory manager
> 3. Inconsistent with other value types (all zero bits)
>
> So -> Better error when var is not initialized than this special value
>

Let me disagree to you

1) Every struct/class needs special initializer because datatypes definitely are different. According to your logic user should initialize all fields to zero and only zero. No other values are possible. It is really strange point.
2) Again you argue against non-zero initialized fields in aggregate types.
3) Once again - not all types should be zero initialized. For example, covariance matrix in Kalman Filter should NOT be initialized to zero. In other case the filter won't work at all.
4) No, you are wrong again. sum accumulator should not start with zero, in other case sum algorithm has no this argument at all, right?
```

On Friday, 19 August 2022 at 13:42:58 UTC, Hipreme wrote:

>

As someone coming from Java to use D, I find it myself quite annoying that float and double are initialized to `nan`.

Honestly have no opinion on float.init being NaN, I don't think I would care either way.

On Saturday, 20 August 2022 at 21:07:33 UTC, Bastiaan Veelo wrote:

>
``````import std;

alias Distance = Typedef!(double, 0.0, "distance");
alias Temperature = Typedef!(double, 0.0, "temperature");

void main()
{
Temperature t;
Distance d;
d += 4.5;
// t = d; // does not compile
}
``````

However, type information can get lost in intermediate results:

``````    t = 0.5 + d; // result is double
``````

It's very simple and beautiful. Thank you, very delicious!

SDB@79

On Sunday, 21 August 2022 at 16:51:51 UTC, Walter Bright wrote:

>
1. compiler complains that `double x;` needs an initializer. To shut up the compiler, the user initializes it to 0, without putting much thought into it. bar(0) may exhibit problems, but these won't necessarily be noticed.

In many cases, `0` can solve that problem.
The real problem is that sometimes it is not appropriate to initialize with 0.
The compiler should collect these 0 initialization locations to better track possible `mistakes`.

On Monday, 22 August 2022 at 01:09:53 UTC, Salih Dincer wrote:

>

It's very simple and beautiful. Thank you, very delicious!

except for ugly error messages :(

```On Sunday, 21 August 2022 at 19:57:52 UTC, apz28 wrote:
> Price for this float=NaN & char=FF
> 1. Runtime bloat -> all struct/class with (float or char) need special initializer
No. If intentional you can explicitly leave them uninitialized (= void)

> 2. Slow -> all struct/class not able to utilize zero initialized from memory manager
Fill with specific pattern is _really_ fast, so very very low performance lost - and only once as you shouldn't do initialization in a loop, do you?

> 3. Inconsistent with other value types (all zero bits)
I agree to this, but you choose the wrong solution.
Correct would be to initialize the remaining types also with an invalid value instead of zero.

Why? For this to be an argument on its own, it should not refer to (1)..(3)

So: no argument left. Too bad.
```

On 8/21/22 12:51 PM, Walter Bright wrote:

>

Consider the following pattern, which doesn't appear frequently, but frequently enough:

double x;
if (condition) {
x = 5;
...
}
...               // (1)
if (condition) {
foo(x);
}

Imagine there's a lot more code omitted which obscures the pattern. This code is correct.

Now, maintainer adds `bar(x)` at (1).

The scenarios:

1. x is default initialized to NaN. bar(x) produces a NaN result on everything dependent on x. User knows there's a problem.

How? No exception is thrown, no error occurs. Unless bar somehow checks for NaN, nothing happens. Just like it is for 0. Perhaps it saves the result of bar computation to something for later use. Then that now gets propagated to some other use, and then, deep somewhere, NaN appears in something that appears completely unrelated to bar or x. How do you trace it back?

>
1. x is default initialized to 0. bar(0) may exhibit problems, but these problems won't necessarily be noticed.

Just like NaN.

>
1. compiler complains that `double x;` needs an initializer. To shut up the compiler, the user initializes it to 0, without putting much thought into it. bar(0) may exhibit problems, but these won't necessarily be noticed.

2. compiler complains that `double x;` needs an initializer. Coder just schlepps in a 0. Yes, this happens. Maintainer wastes time wondering why x is initialized to 0, as that may be a nonsense value for x. Maintainer wonders if this unused initialization has a purpose, maybe it is the result of a bad refactoring? Wastes more time investigating it.

Huh? Why are there 2 identical situations here?

I'll also point out that not initializing an integer is sometimes intentionally done (because it's equivalent to initializing to 0). If I see someone didn't assign a value to an int, I don't question if it was an accident, I expect that they meant it.

Also, you forgot:

1. Maintainer expected x to default to 0 (because that's what most types do), and expected bar to be called with 0 or 5. Now, since bar saved the result of it's calculation elsewhere, and then far away from this code, the result is used in some computation that finally makes its way to output in some fashion (and possibly not a specific printing of the value), now there's a puzzle to solve, and no way to know it can be traced back to x without hours/days of searching.
>

D chose option 1.

And there's probably no way that it changes. But in my mind the correct answer is to intialize to 0.

-Steve