proposal: maps: add maps.KeysSlice and maps.ValuesSlice

[cuiweixie]

Since we need to reserve Keys and Values for iterators.
I think we might need to change the old maps.Keys/Values to maps.KeysSlice/ValuesSlice as mention in 513715

[AndrewHarrisSPU]

Does anyone like CloneKeys() []K, CloneValues() []V?

I'm not sure I'm not bike-shedding, but Clone might communicate the allocation of the returned slice, and the shallow copy semantics. slices uses Clone to mean shallow copy.

[andig]

Does anyone like CloneKeys() []K, CloneValues() []V?

It does not feel necessary. It's (almost) obvious that a map type object does not have its key and values in slices.

[rsc]

#61900 adds Keys and Values back as iterators.
#61899 adds slices.Collect and slices.Sorted.

With these, the old maps.Keys(m) would become slices.Collect(maps.Keys(m)) and similarly Values.
Better, this idiom:

keys := maps.Keys(m)
slices.Sort(keys)
use(keys)

becomes

use(slices.Sorted(maps.Keys(m))

Are there other pattern uses for maps.Keys (other than sorting them) that we should be sure to cover?

[earthboundkid]

Just my 2¢, but yeah, I feel like as long as slices.Sorted gets added, the uses of maps.KeySlice are infrequent enough that it could just be keys := slices.Append(make([]K,0, len(m)), maps.Keys(m)) those times when you need it.

[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

[willfaught]

Are there other pattern uses for maps.Keys (other than sorting them) that we should be sure to cover?

I suppose creating a set of them using a map[K]struct{}.

[earthboundkid]

You could do that with an iterator and InsertInto.

[rsc]

Finishing this proposal discussion is blocked on #61405.