It is this way because if you do:
m[+0.0] = ...
m[-0.0] = ...

We want the resulting map to have the -0.0 key, not the +0.0 key. We could avoid this situation in most cases by not doing the copy if the key type is "well-behaved" (the type's equality is byte-by-byte equality).

Is there a rationale for why it's desirable to replace the +0.0 key with -0.0 in that case?

For what it's worth, I just tested C++, Python, and Java, and their standard map types all seem to prefer preserving preexisting key values (including for the -0.0 and +0.0 case, except for Java because its boxed Double type treats -0.0 and +0.0 as unequal).

I don't think it is in the spec, so we could possibly change the behavior. It seemed to be the least surprising behavior at the time. Last assignment wins.

In Russ' example, suppose you had a map from strings to something. Suppose the strings were small but potentially keeping large buffers live. You could do:

for k, v := range m {
    m[string([]byte(k))] = v
}

To allocate only the backing store required for the existing strings. If the behavior was the other way around (first write wins) there's no way to fix the map. You'd have to allocate a new map.

Hm, I was going to suggest you could do

for k, v := range m {
    k = string([]byte(k))
    delete(m, k)
    m[k] = v
}

but rereading the Go spec's wording about map iteration, that doesn't seem guaranteed to avoid redundant work or even to terminate. :-/

Thanks, Keith. I had forgotten about the -0/+0 case. That's definitely the reason.

I thought for a little while about having a bit in the type that says whether it contains any floats, and do the assignment only then, but it seems not worth it, at least not until someone comes up with a non-hypothetical problem.

We already have that bit, it is called reflexivekey (in runtime.maptype). It's used to recognize that NaN stuff will never happen, but could also be used to recognize that +0/-0 stuff will never happen. It wouldn't be hard to avoid the copy in that case.

CL https://golang.org/cl/10843 mentions this issue.

Just wondering if the case Bool, .. should return false and the case Float, .. return true in https://go-review.googlesource.com/#/c/10843/1/src/reflect/type.go 's needKeyUpdate?

You are right, the return values are wrong. I'll fix it.