[Issue 13420] double.nan unusable as AA key

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13420

hsteoh at quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh at quickfur.ath.cx

--- Comment #3 from hsteoh at quickfur.ath.cx ---
What *should* be the behaviour of an AA with a key type that can take on values
that don't equal themselves?

Suppose you're given an opaque type K, and for all instances k1, k2 of K, k1 !=
k2 (even when k1 and k2 have the same binary representation)? Basically, the
only sane way to store such keys in an AA would be to use its binary
representation... but that breaks down as soon as K contains indirections.
Should such key types even be valid AA keys??

Also, an AA with floating-point key also suffers from the problem that, unless
you're expecting to look up the exact binary representation, it's effectively
worthless (e.g., if 10.0 is a key in an AA, then I try to look up the result of
some arbitrary computation that I expect to be equal to 10.0, then it may fail
due to roundoff error during said computation). There is currently no such
thing as approxEqual lookup of a floating-point AA key, so there is no way
around this. (You'd have to use an interval tree or something like that
instead.) So it would seem that when it comes to floating-point AA keys, we're
really looking at dealing with the binary representation of the values, not the
logical semantics of the values.

In this sense, I argue that existing code that uses floating-point AA keys is
already broken -- recently, for example, there was a PR to make aa[0.0] the
same thing as aa[-0.0]. Logically this may make sense, but then you have to
deal with NaN being never equal to itself, and there's no way a generic AA
implementation can deal with this satisfactorily (at least, not without
breaking the IEEE floating-point semantics).

The only sensible solution I can see is to treat floating-point keys as their
binary representations instead of their logical meaning, which means that
aa[0.0] and aa[-0.0] should be distinct. Which would mean reopening the bug
associated with the PR that treated 0.0 as equal to -0.0.

--