proposal: x/exp/maps: add Merge

[louisportay]

Prior to my PR, I didn't see that this feature was already discussed here.

Even though the change was retracted in favor of maps.Copy, I believe that for a large number of maps to merge, the semantics of a Merge function are more meaningful.

The implementation I've proposed has no mechanism for key conflicts resolution.
But this mechanism (if implemented) could possibly justify this function existence alongside maps.Copy.

[seankhliao]

what's the proposed API?
and do you have numbers to back up your claim?

[louisportay]

Here's the proposed API
func Merge[M ~map[K]V, K comparable, V any](m ...M) M

What I'm saying is

m := maps.Merge(m1,m2,m3,m4,m5)





is more explicit IMO than









m := maps.Clone(m1)
maps.Copy(m, m2)
maps.Copy(m, m3)
maps.Copy(m, m4)
maps.Copy(m, m5)


The other benefit of this function is the ability to allocate one time to hold every values in a single map.

[rsc]

I don't know: the maps.Clone+maps.Copy implementation seems more explicit to me. There is no ambiguity about which maps override which other maps.

I don't understand the comment about the benefit of "the ability to allocate one time". Perhaps this is talking about precalculating the size of the map and preallocating, but that doesn't end up working that well for maps, and it's difficult to predict the amount of overlap anyway. If m1 through m5 contain mostly the same keys, you need max(len(mX)) for the result. If they contain mostly different keys, you need sum(len(mX)) for the result. Those are very different preallocated sizes.

[rsc]

This also doesn't seem like a very common operation. How important is this? How often does it come up?

[rsc]

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

[rsc]

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