https://issues.dlang.org/show_bug.cgi?id=13420
--- Comment #4 from yebblies <yebbl...@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. --