float init 0 request

[Steven Schveighoffer]

On Saturday, 15 August 2026 at 06:11:23 UTC, Walter Bright wrote:
> On 8/14/2026 2:25 PM, Steven Schveighoffer wrote:
>> In all the years I have used D, whenever I have forgotten to 
>> initialize a floating point number, the fix was ALWAYS to 
>> initialize explicitly to 0, because that's what I expected and 
>> desired to happen.
>
> Yes, initializing to 0.0 is very common. And that works fine 
> until the correct initialization is 0.001, and there's an 
> unrecognized bug in the output.

1. If this was the correct value, I would initialize it to 0.001. 
What if the correct value is 0.001 and you accidentally use 0.01?
2. If you forgot, the chances of 0 not showing up somewhere are 
slim. If it's supposed to be a factor, all of a sudden all your 
values are unexpectedly 0. If it's supposed to be an epsilon, 
then most likely your code fails to work correctly. If it's 
supposed to be an addition factor, then likely 0 is close enough 
that it's not important, or it makes a difference and you notice.
3. NaN isn't significantly more likely to be seen than erroneous 
0. Most code that uses floats doesn't print them. NaN has weird 
properties. Maybe it's used in a comparison, and is always false. 
How is that obvious? Ever see NaN show up on a UI? How is that 
possible since NaN is so obvious to the developer they would have 
fixed it before release?
4. I would actually be *OK* with NaN as a default if it failed on 
first use. The problem with it is that it propagates far away 
from the actual error. Null is different, it fails immediately 
and loudly.
5. What about ints? Sometimes the default value of 0 is not 
right, and it should be 1. How do we cope with programming when 
ints default to 0?

0 is a better default, a consistent default, an expected default, 
and good default values make programming more pleasant.

>> This is a big stain on D, and it disrupts everyone's work 
>> unnecessarily. The problem is the distance from the error to 
>> the result.
>
> The problem with default initialization to 0.0 is not 
> recognizing that the result is in error, which I submit is much 
> much worse. It costs orders of magnitude less money to fix a 
> bug made very visible with a NaN output than output that is 
> just slightly wrong and unnoticed out in the field.

This is just hypothesizing. If 0 isn't the right value, then most 
likely you will see the error. Show some real world examples of 
NaN showing up when *erroneous* 0 would not have. In all my 
cases, NaN shows up because it *should have been* 0.

> When reviewing code, and you see:
> ```d
> float f;
> ```
> is the intention to initialize it to zero, or did the 
> programmer simply forget to initialize it? I've had more than 
> enough of the latter in actual code.

```d
int i;
```

Same thing.

In D, it is reasonable to expect a 0 init for a declared 
variable. I use it all the time.

If you are used to C, yeah, the default (random data) is bad.

Note that at least C has `= {0}` which allows you to zero 
everything in a struct regardless of nested data structure. D 
doesn't have this.

>
> P.S. In case it isn't obvious, this derives from my experience 
> designing flight controls for the 757. You really really really 
> want to find all the bugs before cutting metal or, heaven 
> forbid, trying to lift it off the runway. Inconvenience be 
> damned.

It's not obvious how this is relevant. NaN's are in actual 
released code, I've seen them. They do not magically expose all 
errors. What prevents errors is actual good tests.

And you can always init to NaN explicitly if you want, just like 
today you can init to 0 if you want.

0 being correct is way way way more likely than NaN exposing a 
bug that an erroneous default 0 would not. This just makes for 
more busywork for the developer, for zero benefit.

-Steve