I disagree with this proposal. IMHO there is a semantical difference between Equal/EqualFunc and Copy that should be preserved on the function signature.

When comparing two maps for equality, m1 and m2 are "equally" important, in the sense that neither will be modified and for the purposes of the return boolean, it doesn't really matter which one is different. Your code may consider one of them as preeminent, but this isn't relevant to the function implementation.

With Copy instead, the first map dst is indeed modified, so there is a preeminence relationship. Whether it is dst over src or the other way around isn't necessarily important. What's important is that the relationship exists, hence it makes sense that both have the same type (parameter) on the function signature.

This way if you have some specific code where the types don't matter, you would use an explicit conversion:

	a := A{"foo": "1"}
	b := B{"bar": "2"}
	maps.Copy(a, A(b))

Note that in real code the type declarations may be far away from the point of usage, so forcing the explicit conversion makes for clearer code.

I prefer to think of it more practically: What do we gain as writers and readers of code?

Is it more clear as a reader if there's an explicit conversion? It doesn't seem so. If you see maps.Copy() it's pretty clear what that's doing irregardless of the two types involved. Is it important when reading the code to know the types are different at that point? Probably not, it seems more important that they're actually the same.

Does a writer gain any safety? Could it prevent a mistake where I have three maps, two of the same type and one of a second and I accidentally put in the wrong variable? It could - though it seems unlikely that this case is going to arise frequently enough to make decisions based on that possibility alone. Furthermore it may not be possible to access the map types to perform the conversion since they would have to be exported, and then you've no recourse remaining other than copy-pasting the implementation of maps.Copy - though not having have access to both map types is equally unlikely as juggling 3 maps with only 2 being of compatible type, but the consequences are certainly grating if it occurs.

I see this as a simple improvement in ergonomics. If I'm calling maps.Copy on these two variables of different types I probably have a pretty good idea of what I'd like to do with them and the extra conversion doesn't seem helpful to code writers (for safety) or readers (for readability) in my estimation. I have no statistics to back up these claims, just my own experience which may not weigh enough to get this proposal accepted in the face of disagreements.

Since maps.Copy() is essentially a map analogue of the built-in copy() function, it makes sense for it to have the same semantics as that, and that works just fine on compatible slices of different types.

We added the M type parameter to match the many other functions in the package.
If that poses a problem for Copy, instead of having M1, M2, we could have no M parameter at all - just K and V.
Because the maps are only passed in, not returned, that will handle named maps automatically.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

No parameter at all would make it inconsistent with other functions signatures, and actually lose flexibility in the (rather uncommon) case of declaring variables of function type.

type MyDictionary map[string]interface{}

fn := maps.Copy[MyDictionary]
// ...
fn(m)

If a change must be made, it's better to have M1 and M2 than no M parameter at all.

Ian points out there are other functions with two map parameters, like Equal, so I take back my suggestion to have zero.

Code like

package maps
func Copy[M1 ~map[K]V, M2 ~map[K]V, K comparable, V any](dst M1, src M2)

type MyDictionary map[string]interface{}
fn := maps.Copy[MyDictionary]

will not work with two parameters. You will have to write:

fn := maps.Copy[MyDictionary, MyDictionary]

This seems somewhat awkward. On the other hand, if you have one parameter, this fails:

type A map[string]string
type B map[string]string

maps.Copy(make(A), make(B)) // compile error

That doesn't bother me a lot because this doesn't type-check either:

var a A
var b B
_ = a == b // mismatched types

Of course if you really want to force it, you can do:

maps.Copy[map[string]interface{}](make(A), make(B)) 

or

maps.Copy[map[string]interface{}](make(A), A(make(B)))

On the other hand, Equal already takes two. (In fact Copy is the only function that takes two maps as arguments but only has one type parameter.) So probably Copy should match.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Change https://go.dev/cl/408894 mentions this issue: maps: permit Copy between two diffent generic map types