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.
