Why Go Spent Two Months Debating maps.Same – The Proposal Finally Accepted

Go maps are reference types, so two map variables that share the same underlying hash table refer to the same data. The language, however, forbids using == to compare maps for identity, allowing only a comparison with nil. Developers historically resorted to the heavyweight pattern

reflect.ValueOf(x).UnsafePointer() == reflect.ValueOf(y).UnsafePointer()

, which incurs significant runtime overhead.

A new proposal adds maps.Same(x, y) to the standard library. The function performs a single pointer comparison that the compiler reduces to a CMP instruction, delivering essentially zero overhead while remaining type‑safe and memory‑safe.

The proposal sparked a naming controversy. The original name Identical conflicted with types.Identical, which checks type equivalence, not pointer identity. Community members suggested IsAliased or Aliased, and another pointed to os.SameFile as a precedent. The committee ultimately adopted Same for its simplicity and reduced ambiguity.

Semantic edge cases were also debated. Two nil maps are considered the same, preserving consistency with m == nil. However, maps containing NaN keys can produce surprising results because NaN != NaN. The documentation now includes a warning and an example where union(s, s) returns a set with only one element when s contains a NaN key.

The generic signature of the function evolved through three versions. Version 1 required two independent type parameters sharing the same key type. Version 2 simplified to shared K and V types, covering most use cases. A more aggressive version 3 allowed completely different key and value types, but the committee rejected it to preserve compile‑time type checking and avoid always‑false results when mismatched types are passed.

A parallel discussion considered adding a similar Same function to the slices package. Because slices have both value semantics ( len, cap) and reference semantics (underlying array pointer), determining “reference equality” is far more nuanced. The existing private overlaps helper handles specific cases but is not suitable for a generic API, so the proposal was excluded from the current effort.

After more than two months of discussion across four fronts—naming, nil handling, NaN pitfalls, and generic signatures—the proposal was accepted. The implementation CL 794421 has been submitted, illustrating Go’s philosophy of careful, backward‑compatible standard‑library evolution rather than rapid, unchecked feature addition.

Reference links:

Proposal original discussion: https://github.com/golang/go/issues/78456

Implementation CL: https://go.dev/cl/794421

Go proposal process overview: https://go.dev/s/proposal-status