Movement against float.init being nan

[Walter Bright]

On 8/22/2022 7:06 AM, Steven Schveighoffer wrote:
>> It's not as convenient as a segfault but at some point, the error becomes 
>> obvious.
> Does it? And "at some point" it becomes obvious no matter what the error you made.

The point is, since 0.0 is a common value for a floating point value to be, just 
when does it become obvious that it is wrong? Are you really going to notice if 
your computation is 5% off? Isn't it a *lot* more obvious that it is wrong if it 
is NaN?


>> I would start there to inspect variables, identify the NaNs.
> What if you can't? What if it only happens randomly, and you don't just happen 
> to have a debugger attached?
> I'm not saying it's easier with 0, but just not any different.

0.0 is hardly a rare value, even in correct calculations. NaN is always wrong.


>> Then I would trace them in a debugger and go up the call chain until I find 
>> the location where it became NaN. Then I would identify the source which 
>> introduced the NaN and trace that back until I found its origin.
> If you have a chance to use a debugger and it happens at that time.

0 initialization wouldn't make it better.


>> The advantage I see in NaN is that it's always (instead of only almost always) 
>> immediately obvious that it's wrong whereas 0.0 can be valid or invalid so you 
>> need to figure out which one it is which requires an extra step.
> It might be noticed that it's NaN. It also might not. It depends on how it's used.

NaN propagates. 0.0 does not.


> Either way, you need to find the source, and NaN doesn't help unless you want to 
> start either instrumenting *all* code (possibly including code you don't 
> control), or use a debugger (which isn't always possible).

Such a situation is objectively worse with 0.0. Is instrumenting all the code to 
detect 0.0 going to work? Nope, too many false positives, as 0.0 is a common 
value for floating point numbers.


> Can we have some kind of linting system that identifies NaNs that are used?

I have no objection to a linter that flags default initializations of floating 
point values. It shouldn't be part of the D compiler, though.