[Issue 13420] double.nan unusable as AA key

[via Digitalmars-d-bugs]

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

--- Comment #4 from yebblies <yebblies at gmail.com> ---
(In reply to hsteoh from comment #3)
> What *should* be the behaviour of an AA with a key type that can take on
> values that don't equal themselves?

Exception.  Or assertion failure, depending on if we decide it's an input error
or a program error.

> 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??

No.

> 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).

Having multiple keys compare as equal is fine, so long as the hash and
comparison match.

> 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.

No, if somebody wants to use the binary rep of a floating point type as a key
they should a) wrap it in a struct that explicitly overrides the hash and
comparison or b) reinterpret cast it to a type that works that way.

--