It's not clear to me why the proposed behavior is any better than the current behavior. The old behavior is consistent with the built-in maps rule that nil maps panic only when written to.

I don't think we can change the behavior now. This API has already been released and people may be depending on the old behavior, even if unspecified in the docs.

The old behavior is consistent with the built-in maps rule that nil maps panic only when written to.

I would have said the opposite; I find the proposed behavior more consistent with the built-in maps rule, but now I also understand your perspective.

I'd suggest documenting the current behavior at this point; it's not quite evident without delving into the code.

CC @eliben, @Deleplace.

I agree with most of the arguments, though IMO any usage of Copy with dst==nil is a bad idea (not a legit use case, and the developer shouldn't rely on Copy always panicking or never panicking in this case).

Keeping and documenting the existing behaviour should be fine:

Copy panics if dst is nil and src contains at least one element to be copied.

As far as I could see, there are two ways we can take:

1. Documenting the current behavior, which is acceptable.

2. Addressing the issue of it throwing an error when the destination is nil and the source isn't.

Personally, I would prefer the second approach. The rationale behind this choice is that if we are copying, it is likely that we are allocating space in a new memory address if it does not exist yet.

The function maps.Copy should retrieve the value from a source and either copy it to the destination if it exists or allocate memory and then copy the values. It shouldn't crash in such a scenario.

I can take that to solve, if you guys don't mind

I don't think maps.Copy has any way to allocate memory (a new map) and provide it to the caller who passed nil, because maps.Copy doesn't return a collection like append or maps.Clone.