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.

[gopherbot]

Change https://go.dev/cl/535215 mentions this issue: runtime: use real type size in map keys and values functions

[rsc]

The key issue seems to be #61626 (comment).
It sounds like if we add maps.Keys, maps.Values, and slices.Collect, then we can use

KeySlices(m) => slices.Collect(maps.Keys(m)) (or slices.Sorted(maps.Keys(m)))
ValuesSlice(m) => slices.Collect(maps.Values(m))

and do not need to add these explicitly.

[rsc]

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

[andig]

and do not need to add these explicitly.

Need, no. Make devs life easier and Go more approachable yes.

[mibk]

I feel like the issue is #61900 (comment). I agree it's more elegant to write a single line instead of three, but I don't mind writing those extra lines for the sake of optimization.

[earthboundkid]

I think it’s a little too soon to permanently decline these. I think we definitely can skip them for now, but it may be that after a few years of experience there turns out to be some reason they are needed after all and this can be reopened then.

[earthboundkid]

@Nasfame See also #61900.

[rsc]

I think it’s a little too soon to permanently decline these.

Decline is never permanent. Only accept is permanent.

[rsc]

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

[andig]

Having to write

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

to avoid excessive allocations still seems really cumbersome and little approachable to new devs. Given this would be best practice for performance (as @earthboundkid said "those times when you need it"), it couldn't hurt to make this easier to use other than resorting to x/exp/maps.

[fzipp]

Maybe, but why not wait a couple of years and then analyse the Go corpus to determine if it warrants an addition to the standard library.

it couldn't hurt to make this easier to use other than resorting to x/exp/maps.

Every addition to the standard library hurts. The question is whether the benefits outweigh this hurt.

[andig]

Imho the argument is above. Writing code that doesn't allocate more than necessary seems worth it imho and hasn't been specifically mentioned before.

[fzipp]

Imho the argument is above. Writing code that doesn't allocate more than necessary seems worth it imho and hasn't been specifically mentioned before.

It has been mentioned before:
#61900 (comment)
#61900 (comment)

[andig]

Decline is never permanent. Only accept is permanent.

Would this be a suitable proposal to be reopened? #68261 does not seem like an attractive alternative.