Which D features to emphasize for academic review article

[F i L]

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.