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
Comment From: 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.
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: 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
Comment From: 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{}.
Comment From: earthboundkid
You could do that with an iterator and InsertInto.
Comment From: rsc
Finishing this proposal discussion is blocked on https://github.com/golang/go/issues/61405.
Comment From: gopherbot
Change https://go.dev/cl/535215 mentions this issue: runtime: use real type size in map keys and values functions
Comment From: rsc
The key issue seems to be https://github.com/golang/go/issues/61626#issuecomment-1672096753. 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.
Comment From: rsc
Based on the discussion above, this proposal seems like a likely decline. — rsc for the proposal review group
Comment From: andig
and do not need to add these explicitly.
Need, no. Make devs life easier and Go more approachable yes.
Comment From: mibk
I feel like the issue is https://github.com/golang/go/issues/61900#issuecomment-1917362371. 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.
Comment From: 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.
Comment From: earthboundkid
@Nasfame See also #61900.
Comment From: rsc
I think it’s a little too soon to permanently decline these.
Decline is never permanent. Only accept is permanent.
Comment From: rsc
No change in consensus, so declined. — rsc for the proposal review group
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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: https://github.com/golang/go/issues/61900#issuecomment-1917362371 https://github.com/golang/go/issues/61900#issuecomment-1927237547
Comment From: andig
Decline is never permanent. Only accept is permanent.
Would this be a suitable proposal to be reopened? https://github.com/golang/go/issues/68261 does not seem like an attractive alternative.