Just repeating myself from the other issue: We might want maps.Copy to take an iterator as its second argument, in which case, it should also be held back from 1.21 just in case.

Could this be resolved by having a special naming convention for iterator variants of allocating functions? E.g. we could ship maps.Keys now, and add maps.KeysIter later?

Edit: The reason for pulling maps.Keys was that it forces allocation, but returning an iterator imposes the opposite problem: what if I want a slice of keys? I'd have to allocate the slice, iterate through and build up the slice, etc. I'm not sure there's a right "default" approach here; both variants are useful.

Building a slice from an iterator doesn't necessarily require any extra allocation:

package iters

func Append[T any](s []T, iter Iter[T]) []T {
  for v := range iter {
    s = append(s, v)
  }
  return s
}

Then you can just append the maps.Keys() iterator directly into a preallocated slice. It'll essentially do what maps.KeysSlice() would do internally.

That being said, I do think that maps.KeysSlice() should exist, as otherwise the one-line way of getting a slice of the keys would be

keys := iters.Append(make([]T, 0, len(m)), maps.Keys(m))

which is really kind of awkward.

@AndrewHarrisSPU
The issue for discussion of functions to return map keys and values as slices is #61626.

My initial reaction to this was this seemed a bit heavy handed, but the more I thought about it in relation to the range over function proposal and it's impact over existing data containers got me thinking.

One of the the things that I think, @ianlancetaylor say at one point is, it would be nice to define additional map types using generic type parameters instead of special builtin types defined only in the runtime. For example there could be a OrderedMap[K, V] or a equivelent of rusts BtreeMap. These are do-able today with type parameters, but become much more powerful when we can have them be natively iterated over by #61405.

Would a the existing maps be able to handle custom types like these in the future or should that even be a consideration at this time? My guess is custom types and the builtin type are going to be too different to have generic functions that work on both, but I haven't put much thought into it.

Pulling all of maps seems strictly more disruptive than pulling just Keys and Values.
There are no concerns about the remaining API.
Copy is a fine name for what it does.
People who need both Equal and Keys can continue to import one package, namely golang.org/x/exp/maps.

No change in consensus, so declined.
— rsc for the proposal review group