Handling NaN Keys in Go Maps and the Proposal to Add delete(m) for Clearing Maps

In Go language discussions, the handling of NaN (Not a Number) values in maps has caused repeated debates because NaN does not compare equal to any value, including itself, which leads to unexpected behavior when clearing maps.

NaN, introduced by the IEEE‑754 floating‑point standard in 1985, is a special floating‑point value representing undefined or unrepresentable results. Comparisons involving NaN always return false except for the inequality test, which returns true . The following table summarizes these results:

Comparison

Result

NaN ≥ x

False

NaN ≤ x

False

NaN > x

False

NaN < x

False

NaN = x

False

NaN ≠ x

True

A Go101 quiz illustrates these semantics. The program below creates +Inf values and two NaN values, then compares them:

package main

import "math"

func main() {
    a, b, c := 2.0, 1.0, 0.0
    x, y := a/c, b/c // infinity
    n := math.NaN()      // not a number
    m := math.Sqrt(-1.0) // not a number
    println(x == y, m == n)
}

The correct answer is B (output: true false ), because the two infinities compare equal while the two NaN values do not.

When it comes to clearing a map, the Go team traditionally recommends iterating over the map and deleting each key:

for k := range m {
    delete(m, k)
}

However, if a map contains a NaN key, this loop fails to remove the entry because the NaN key never matches during iteration, effectively causing a memory leak.

To address this, Russ Cox has reopened a proposal ( proposal: spec: add delete(m) to clear map ) that introduces a new built‑in function delete(m) which clears the entire map regardless of its contents, including NaN keys.

Example usage of the proposed API:

delete(m)

The proposal also sparked a naming debate: some prefer clear while others argue for keeping the existing delete terminology. A draft Clear generic function is shown for reference, but the core idea remains the same—provide a reliable way to empty a map.

Since Go 1 already permits NaN values in maps, the language cannot simply forbid them, making this API addition the most practical solution to the problem.