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.
