How about the case where x is (y > 0)? If y is NaN, shouldn't x be boolean-NaN? And shouldn't if(x) throw an exception? Or shouldn't (y > 0) throw an exception if you don't want boolean-NaNs?
Again, I think it would be _really_ weird for simple value comparisons to throw.
But ... why?
You may say that NaN > 0 is defined as False, but we know that's not how programmers think, most of the time.
In code like if(y > 0) steer_car_to_left() I don't want the compiler or the IEEE standard to make any choices for me! Let it throw, so emergency systems can kick in.
Comments
How about the case where x is (y > 0)? If y is NaN, shouldn't x be boolean-NaN? And shouldn't if(x) throw an exception? Or shouldn't (y > 0) throw an exception if you don't want boolean-NaNs?
That's easy: y > 0 is False, not NaN.
You may not think this is wise, but this is very much how comparisons with NaN are defined.
And I think this is better than exception raising. Again, I think it would be _really_ weird for simple value comparisons to throw.
But ... why?
You may say that NaN > 0 is defined as False, but we know that's not how programmers think, most of the time.
In code like if(y > 0) steer_car_to_left() I don't want the compiler or the IEEE standard to make any choices for me! Let it throw, so emergency systems can kick in.