Walter Bright wrote:
It catches only a subset of these at compile time. I can craft
any number of ways of getting it to miss diagnosing it.
Consider this one:
float z;
if (condition1)
z = 5;
... lotsa code ...
if (condition2)
z++;
To diagnose this correctly, the static analyzer would have to
determine that condition1 produces the same result as
condition2, or not. This is impossible to prove. So the static
analyzer either gives up and lets it pass, or issues an
incorrect diagnostic. So our intrepid programmer is forced to
write:
float z = 0;
if (condition1)
z = 5;
... lotsa code ...
if (condition2)
z++;
Yes, but that's not really an issue since the compiler informs
the coder of it's limitation. You're simply forced to initialize
the variable in this situation.
Now, as it may turn out, for your algorithm the value "0" is an
out-of-range, incorrect value. Not a problem as it is a dead
assignment, right?
But then the maintenance programmer comes along and changes
condition1 so it is not always the same as condition2, and now
the z++ sees the invalid "0" value sometimes, and a silent bug
is introduced.
This bug will not remain undetected with the default NaN
initialization.
I had a debate on here a few months ago about the merits of
default-to-NaN and others brought up similar situations. but
since we can write:
float z = float.nan;
...
explicitly, then this could be thought of as a debugging feature
available to the programmer. The problem I've always had with
defaulting to NaN is that it's inconsistent with integer types,
and while there may be merit to the idea of defaulting all types
to NaN/Null, it's simply unavailable for half of the number
spectrum. I can only speak for myself, but I much prefer
consistency over anything else because it means there's less
discrepancies I need to remember when hacking things together. It
also steepens the learning curve.
More importantly, what we have now is code where bugs-- like the
one you mentioned above --are still possible with Ints, but also
easy to miss since "the other number type" behaves differently
and programmers may accidentally assume a NaN will propagate
where it will not.
This is incorrect, as the optimizer is perfectly capable of
removing dead assignments like:
f = nan;
f = 0.0f;
The first assignment is optimized away.
I thought there was some optimization by avoiding assignment, but
IDK enough about memory at that level. Now I'm confused as to the
point of 'float x = void' type annotations. :-\
Whether you agree with it being a good feature or not, it is a
feature unique to D and merits discussion when talking about
D's suitability for numerical programming.
True, and I misspoke by saying it wasn't a "selling point". I
only meant to raise issue with a feature that has been more of an
annoyance rather than a boon to me personally. That said, I also
agree that this thread was the wrong place to raise issue with it.
