Quote:Original post by Nitage
- IMO the rational for NaN being part of the language instead of the library is covering for the fact that D's comparsion operator can't express the NaN relationship ( ie NaN > NaN, NaN == NaN and NaN < NaN are all false). The language also doesn't account for the fact that many object have a sensible equality relationship, but no sensible greater than or less than relationship

Visit the spec on expressions at: http://digitalmars.com/d/expression.html
Search the page for the text: Floating point comparison operators
You will see a chart of all the relational expressions for float/double/real/etc. Included therein is, for example, (!>=) meaning "Unordered or less than." If you want to test if some variable "foo" is a NaN, then you simply test it against itself for the unordered case:
if (foo !<>= foo) { ... }

Or did I misunderstand the post?

And the equality relationship versus greater/lesser relationship is covered. You overload opEquals for the former and opCmp for the latter. In fact, to use objects as keys in an associative array, you have to provide both of those overloads. opEquals for key matching, and opCmp for the hash tree that implements the array. (There are default implementations of opEquals and opCmp, but I've yet to see any code that relied on them.)