Walter Bright wrote:
I'd rather have a 100 easy to find bugs than 1 unnoticed one that went out in the field.
That's just the thing, bugs are arguably easier to hunt down when things default to a consistent, usable value. When variables are defaulted to Zero, I have a guarantee that any propagated NaN bug is _not_ coming from them (directly). With NaN defaults, I only have a guarantee that the value _might_ be coming said variable.
Then, I also have more to be aware of when searching through code, because my ints behave differently than my floats. Arguably, you always have to be aware of this, but at least with explicit sets to NaN, I know the potential culprits earlier (because they'll have distinct assignment).
With static analysis warning against local scope NaN issues, there's really only one situation where setting to NaN catches bugs, and that's when you want to guarantee that a member variable is specifically assigned a value (of some kind) during construction. This is a corner case situation because:
1. It makes no guarantees about what value is actually assigned to the variable, only that it's set to something. Which means it's either forgotten in favor of a 'if' statement, or in combination with an if statement.
2. Because of it's singular debugging potential, NaN safeguards are, most often, intentionally put in place (or in D's case, left in place).
This is why I think such situations should require an explicit assignment to NaN. The "100 easy bugs" you mentioned weren't actually "bugs", they where times I forgot floats defaulted _differently_. The 10 times where NaN caught legitimate bugs, I would have had to hunt down the mistake either way, and it was trivial to do regardless of the the NaN. Even if it wasn't trivial, I could have very easily assigned NaN to questionable variables explicitly.
