"bearophile" <[email protected]> wrote in message news:[email protected]... > 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!".
