Which D features to emphasize for academic review article

[Walter Bright]

On 8/10/2012 9:01 PM, F i L wrote:
> 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;
>      ...

That is a good solution, but in my experience programmers just throw in an =0, 
as it is simple and fast, and they don't normally think about NaN's.

> 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.

It's too bad that ints don't have a NaN value, but interestingly enough, 
valgrind does default initialize them to some internal NaN, making it a most 
excellent bug detector.


> 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.

Sadly, D has to map onto imperfect hardware :-(

We do have NaN values for chars (0xFF) and pointers (the villified 'null'). 
Think how many bugs the latter has exposed, and then think of all the floating 
point code with no such obvious indicator of bad initialization.

> 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. :-\

It would be used where the static analysis is not able to detect that the 
initializer is dead.