int nan

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:h237c9$orl$1 at digitalmars.com...
> The following comes partially from a friend of mine. If you are busy you 
> can skip this post of musings.
>
> From the docs:
> http://www.digitalmars.com/d/1.0/faq.html#nan
>>Because of the way CPUs are designed, there is no NaN value for integers, 
>>so D uses 0 instead. It doesn't have the advantages of error detection 
>>that NaN has, but at least errors resulting from unintended default 
>>initializations will be consistent and therefore more debuggable.<
>
> Seeing how abs(int.min) gives problems, and seeing how CPUs manage nans of 
> FPs efficiently enough, it can be nice for int.min to become the nan of 
> integers (and similar for short, long, and maybe tiny too). Such nan may 
> also be useful for purposes similar to nullable integers of C#.
>
> Bye,
> bearophile

Interesting idea, but IMO using NaN as a default initializer is just a 
crutch for not having a real system of compile-time detecting/preventing of 
uninitialized variables from being read (C#'s system for this works very 
well in my experience). Ie, Default initing to NaN is certainly better than 
default-initing to a commonly-used value, but it still isn't the right 
long-term solution.

Barring that "correct" solution though, I do think it would make far more 
sense for the default-initializer to be something that isn't so commonly 
used as 0. So yea, either int.min, or 0x69696969 or 0xB00BB00B, etc, ie 
something that will actually stand out and scream "Hey! Double-check this! 
It might not be right!".