Related Issues

• x/exp/maps: Equal (and EqualFunc) don't take nilness of maps into account #56621 (closed)
• maps: Equal should not allocate on the heap #65329 (closed)

Related Documentation

• Package maps > func EqualFunc ¶

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Unfortunately, we need to skip this optimization if the key and value types could possibly contain floating point values, which violate the reflexive property of equality for NaNs.

What if a map maintained a hasNaN bool ? Then it is just return !m.hasNaN && !m2.hasNaN && m == m2.

What if a map maintained a hasNaN bool ? Then it is just return !m.hasNaN && !m2.hasNaN && m == m2.

The NaN could be buried within the tree of aggregate (array/struct) values of the key, and the information that hashing encountered a NaN is not returned by the hash algorithm. Annoyingly, for Equal, one must also recursively search the values for NaNs.

Simpler to go by types. The rtype for the keys and values could record a statically computed hasFloat bit so that no recursion is required at runtime.

The old non-Swiss map type recorded ReflexiveKey as a flag on the map type. The new Swiss map type has a flags field. We could copy the old flag code to the new implementation, and use that.

But does this case come up a lot in practice?

But does this case come up a lot in practice?

In my use-case, I was doing a copy-on-write mechanism where I needed to detect if something changed. It is quite likely that I could be comparing a map to itself.

The same is for slices.Equal.

Fortunately for slices, it is possible for users to perform this optimization themselves with something like:

len(x) > 0 && len(x) == len(y) && &x[0] == &y[0]

This doesn't handle NaNs "correctly", but honestly most usages do not care.