proposal: x/exp/slices: add AsKeys #56441
Comments
|
It should be a But better, I think, is to add container/set (#47331). Then it would be |
|
Yes, container/set would obviate the need for this. |
It's mostly not about space savings; it's about using a type that has extra semantics beyond that of a set. (It can contain There have been many arguments about this over the years and people have pretty much settled into their camps. I doubt I will change your mind about it at this late date, and you will probably not change mine. (Though, FWIW, I started on team Anyway I think we should sidestep the debate by getting |
|
Hahaha. I started on team But fair enough. I'll close this as a dup of #47331 and hope that it actually sees some movement one of these days. |
|
cc @ianlancetaylor as FYI / nudge :) |
|
At least for me further work on container/set is pending progress on iterators, for which the next step is #56413. |
One very common operation for slices is to take every element of a slice ([]T) and insert it into a map[T]bool, with value true. That allows O(1) lookups in the slice.
This is (almost) the inverse operation of https://pkg.go.dev/golang.org/x/exp/maps#Keys.
It's pretty easy: allocate a map, transfer items. But it's an awkward sized function: It's big enough to add code weight when written inline (as it typically is) yet small enough that it feels silly to extract a bespoke helper. Package slices could make this a nice, obvious one-liner. Plus package slices won't omit the map size hint out of laziness. :)
I propose that we add this to package slices. I propose
AsKeys, but there are other colors available:AsSet,Set, etc.The text was updated successfully, but these errors were encountered: