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.
