proposal: x/exp/slices: add AsKeys

[josharian]

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.

[cespare]

It should be a map[T]struct{} IMO.

But better, I think, is to add container/set (#47331). Then it would be set.Of(s...).

[josharian]

map[T]struct{} has more verbose lookups, for pretty minimal space savings.

Yes, container/set would obviate the need for this.

[cespare]

map[T]struct{} has more verbose lookups, for pretty minimal space savings.

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 false as a value.)

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 bool before @tv42 convinced me so I suppose it's possible.)

Anyway I think we should sidestep the debate by getting container/set into the library.

[josharian]

Hahaha. I started on team struct{}. :)

But fair enough. I'll close this as a dup of #47331 and hope that it actually sees some movement one of these days.

[josharian]

cc @ianlancetaylor as FYI / nudge :)

[ianlancetaylor]

At least for me further work on container/set is pending progress on iterators, for which the next step is #56413.