NaNs Just Don't Get No Respect

[Chad J]

On 08/17/2012 08:03 PM, Walter Bright wrote:
> Our discussion on this in the last few days inspired me to write a blog
> post about it:
>
> http://www.reddit.com/r/programming/comments/yehz4/nans_just_dont_get_no_respect/
>
>
> http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723

Walter, I know you like to make the easy thing the right thing.  I like 
this notion myself.

So instead of writing

     float f;
     if (condition1)
         f = 7;
     ... code ...
     if (condition2)
         ++f;

is there any way we can make it easier to write

     void someCode() {
         ... code ...
     }

     float f;
     if ( condition )
     {
         f = 7;
         someCode();
         ++f;
     }
     else
         someCode();

assuming that condition2 is true when condition1 is true?

Maybe some other reasonable equivalent snippet could be concocted that's 
easier to discover, and make the language hint in that direction.

I feel like NaNs are a step forward, but better can be done.  They allow 
error detection, but it's still merely runtime error detection, and 
worse yet, it's /non-local/ error detection.  NaNs can spread from 
function to function and end up in completely different parts of a 
program than the place they originated.  This causes debugging hell, 
just like null values.  It makes me think that non-nan-able floating 
point types would be very useful, at least as function arguments, so 
that calling code doesn't have to introduce extra checks for NaNs that 
are either lost cycles or forgotten entirely and bug-ridden.

I really wish we had a way of catching NaNs in the function or line 
where they happen, and not in completely distant parts of the code.