Movement against float.init being nan

[wjoe]

On Monday, 22 August 2022 at 11:41:33 UTC, Steven Schveighoffer 
wrote:
> 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?
>

Assuming this isn't a rhetoric question...
It's not as convenient as a segfault but at some point, the error 
becomes obvious. I would start there to inspect variables, 
identify the NaNs.
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.

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.