Which D features to emphasize for academic review article

[F i L]

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.