Why is a map entry stored under math.NaN() unreachable in Go, and how do you get rid of it?

This is one of the few places where two independent Go rules combine into behaviour that looks like a bug and is not. ### The map accepts the key `float64` supports `==`, so `map[float64]string` is a legal map type and the compiler has nothing to complain about. Nothing in the type system distinguishes a float64 that happens to be NaN from any other float64 — `math.NaN()` returns a perfectly ordinary value of type `float64`. ### The lookup can never match it A Go map find is two steps: hash the key to locate a bucket, then compare the candidate keys in that bucket with `==` to pick the right one. IEEE 754 defines NaN as unequal to everything, itself included, so the second step can never succeed for a NaN key. Three consequences follow, and they are all visible in a few lines: - **Insert always adds.** `m[math.NaN()] = "a"` finds no existing entry to overwrite, so it appends a new one. Do it twice and `len(m)` is 2. Do it in a loop and the map grows without bound while looking, from the outside, like it holds one key. - **Read always misses.** `v, ok := m[math.NaN()]` gives the zero value and `ok == false`, even though the entry is sitting there. - **Delete always misses.** `delete(m, math.NaN())` compares keys exactly as a lookup does, so it removes nothing. Even `for k := range m { delete(m, k) }` fails for these entries: the key handed to you by the loop is a NaN, and comparing it back against the stored NaN is still false. Ranging over the map does yield the entries — iteration walks storage and never compares keys — so you can *see* a NaN entry and read its value, you just cannot address it. In the gc runtime NaN keys are also hashed non-deterministically, so repeated inserts scatter rather than piling into one bucket. ### Removing them `clear(m)` deletes every entry in a map without comparing anything, so it removes NaN entries along with the rest. Rebuilding the map by ranging and copying the keys you want also works, since you never have to match a NaN. There is no way to delete a single NaN entry by key. ### The neighbouring surprise: negative zero While you are here, the other float64 key oddity runs the opposite way. `-0.0` and `0.0` compare equal, so they are *one* key, not two — a value stored under negative zero is found by looking up positive zero. `math.Float64bits` shows they are different bit patterns and `math.Signbit` tells them apart, but the map cannot, because the map only knows `==`. And in Go a constant `-0.0` is simply `0`; you need `math.Copysign(0, -1)` or negating a variable to produce a real negative zero. ### What to do in real code A float64 key is usually a smell in the first place, but when you want one: 1. Reject or normalise at the boundary. `if math.IsNaN(k) { return err }` in the one function that writes to the map is the whole fix, and it costs nothing. 2. Prefer a key that cannot be NaN. Money and quantities keyed as scaled integers (minor units, basis points) are exact, comparable and deletable; a float64 derived from a division is none of those reliably. 3. Treat an unexpectedly growing map as evidence. A map whose `len` climbs while the code only ever writes "the same" computed key is the signature of this bug, and printing `math.Float64bits` of that key in the log confirms it instantly — a NaN shows all exponent bits set with a non-zero fraction, which no ordinary value has. The underlying rule is worth stating once in plain terms: Go maps promise you lookup by equality, and NaN opts itself out of equality. Everything above is that single sentence played out.