You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
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
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.
Activity
AndrewHarrisSPU commentedon Jul 30, 2023
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
usesClone
to mean shallow copy.andig commentedon Aug 4, 2023
It does not feel necessary. It's (almost) obvious that a map type object does not have its key and values in slices.
rsc commentedon Aug 9, 2023
#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:
becomes
Are there other pattern uses for maps.Keys (other than sorting them) that we should be sure to cover?
earthboundkid commentedon Aug 9, 2023
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 commentedon Aug 9, 2023
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 commentedon Aug 15, 2023
I suppose creating a set of them using a map[K]struct{}.
earthboundkid commentedon Aug 15, 2023
You could do that with an iterator and InsertInto.
rsc commentedon Aug 30, 2023
Finishing this proposal discussion is blocked on #61405.
14 remaining items
andig commentedon Jun 30, 2024
Having to write
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 commentedon Jun 30, 2024
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.
Every addition to the standard library hurts. The question is whether the benefits outweigh this hurt.
andig commentedon Jun 30, 2024
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 commentedon Jun 30, 2024
It has been mentioned before:
#61900 (comment)
#61900 (comment)
andig commentedon Aug 3, 2024
Would this be a suitable proposal to be reopened? #68261 does not seem like an attractive alternative.