NaNs Just Don't Get No Respect

[Davidson Corry]

On 8/18/2012 7:36 PM, Nick Sabalausky wrote:
> If that's the case, then the code is far too damn fragile in the first
> place.
>
> This:
>
>      float f;
>      if (condition1)
>          f = 7;
>
> Is bad fucking code, period. I'd expect *ANY* usage of f after that
> (except, of course, a plain assignment to it) to be flagged as an
> error. That's because *even if* f isn't technically used without
> assignment, it still indicates that somebody didn't think their shit
> through and may already be hiding a bug (in which case they're damnned
> lucky it's a float instead of an int) - and even if not, then it's
> still too damn fragile anyway and *will* likely wind up creating a bug
> once someone goes and touches that code.
>
> FWIW, Last time we debated this on the NG, this was the point where
> Walter got stuck on the irrelevant "But it's not garbage-inited like C!"
> strawman. I hope we can do better this time.

With respect, I think that you are conflating two different questions.

If the question is, "should static checking reject this code as 
flawed?", then NaN is irrelevant, and a strawman, yes.

But if the question is, "is default-initializing to NaN better than 
default-initializing to garbage?", then it's entirely on point. (And 
that is the topic of this thread.)

Yes, it would be great if the D compiler (or a C++11 compiler, or C# or 
Scala or what have you) could do a complete static check of the code. As 
a practical matter, today's compiler technology cannot. (And if it 
could, you'd get complaints about compile times... <grin/>)

Since the flaw may not be detected statically at compile time, it's nice 
to know that NaN will detect it at runtime (in the same sense that a 
minefield "detects" an intruder).

Consider how useful *integer* NaN is. Oh, you didn't realize that, when 
you used zero, or minus one, or 0xFFFF or its moral equivalents, to flag 
an error or exceptional condition on a function that returns what is 
normally a number, that you were hand-rolling an integer NaN? For that 
matter, wouldn't it be nice to have a Boolean NaN? (not "true", not 
"false", but "not yet decided")

Except of course that zero, and one, and minus one, and all-bits-set are 
all extremely common and useful *arithmetic* values, and all too likely 
to be returned legitimately. So having a hardware NaN in floating point, 
particularly one that "taints" all future results it participates in, 
and further one that can (by definition) never be a legitimate number, 
is genius. And having Walter design D to take advantage of it is... 
well, perhaps not genius, but damned smart.

I'll build my bricks with Walter's straw, any day.