float init 0 request

[Indraj Gandham]

On Friday, 14 August 2026 at 17:54:25 UTC, Walter Bright wrote:
> I'm afraid we disagree. The null pointer initialization ensures 
> that you cannot dereference an uninitialized pointer and not 
> find out about it. Getting a "NaN" in your program's output is 
> sure to notify the user that there is a BUG in the program. 
> Default initializing to 0.0 runs the high risk of the bug not 
> being noticed.

The difference is that the null ptr will always cause your 
program to crash when you try to use it. The NaN value will not, 
and unless your program prints out every float (or you use 
contracts) it will often be difficult to track down the cause of 
any resulting strange behaviour.

This is the heart of the issue: if you remembered to initialise 
the float, put in a contract or print the value, you probably 
also remembered about the default NaN. But if you didn't, it's 
more likely you wanted 0.0 than NaN. In fact, NaN is almost 
guaranteed to be incorrect, and it'll appear in the places you 
least expect.

> This is why D is better than other languages.

D has many facets which make it the best programming language in 
the world. This is not one of them.

> Consider a scientist setting out an array of data collection 
> sensors. If you've got a lot of them, inevitably some will be 
> bad. A bad one should not bring down the whole system. Having 
> the bad data replaced with NaN will mean the rest of your array 
> data will not be corrupted by a stuck-at-zero problem with one 
> sensor.

This is a contrived example. There are far better, 
well-understood and widely-known anomaly detection techniques the 
scientist could leverage to flag (and remove) faulty sensor data 
before it is processed.

> The worst possible choice is the maintainer shutting up the 
> compiler and initializing it to 0.0 without checking what the 
> correct value should be. And you may never realize that this 
> 0.0 propagated into your output. Yes, this happens. I've seen 
> it happen.

(1) The D compiler does not emit a warning before default NaN 
initialisation.
(2) You're saying it wouldn't be enough anyway, as the user would 
ignore this imaginary warning and would write `= 0` just to shut 
it up.

It appears you are making the argument that instead of warning 
the user about incorrect behaviour at compile-time, and instead 
of inserting the value that the user likely wanted, you are going 
to make them track down garbage at runtime on the off-chance that 
they didn't want 0.0

I hope this is a misunderstanding.