float init 0 request

[claptrap]

On Friday, 14 August 2026 at 17:54:25 UTC, Walter Bright wrote:
> On 8/14/2026 1:17 AM, Indraj Gandham wrote:
>> On Friday, 14 August 2026 at 06:38:02 UTC, Walter Bright wrote:
>>> It's similar to pointers being default initialized to null. 
>>> Trying to use a null pointer will result in a seg fault.
>> 
>> It's not similar at all. There is no sensible init value for a 
>> pointer but there is for a float.
>
> 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.

It's not a guarantee though is it. NaN is a valid result of some 
mathematical operations, so an "uninitialized float NaN" could 
still get lost or hidden.

Heck converting a float to integer and the NaN is gone.

You need to stop acting like it's foolproof, it's really not.

Actually making initialized floats an error would be far more 
useful.


> 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.

Nonsense. "Data collection sensors" don't use floating point. Why 
the hell would they add all the silicon overhead of floating 
point to a sensor IC? They use ints, I've literally never seen a 
floating point one.


> > The NaN value silently propagates and is therefore the worst
> possible choice.
>
> 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.
>
> Having a NaN in your output tells you that your code is broken. 
> A default 0.0 hides bugs.

99 times out of 100 0.0 is the correct value.

So is the 1 time in 100 that NaN helps error early worth the 
other 99 times you get a NaN nowhere near where it actually comes 
from?

Its not as clear cut as you claim it to be.