Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: x/exp/slices: add AsKeys #56441

Closed
josharian opened this issue Oct 26, 2022 · 6 comments
Closed

proposal: x/exp/slices: add AsKeys #56441

josharian opened this issue Oct 26, 2022 · 6 comments
Labels
Milestone

Comments

@josharian
Copy link
Contributor

josharian commented Oct 26, 2022

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.

@gopherbot gopherbot added this to the Proposal milestone Oct 26, 2022
@cespare
Copy link
Contributor

cespare commented Oct 26, 2022

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
Copy link
Contributor Author

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

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

@cespare
Copy link
Contributor

cespare commented Oct 26, 2022

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
Copy link
Contributor Author

josharian commented Oct 26, 2022

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 josharian closed this as not planned Won't fix, can't repro, duplicate, stale Oct 26, 2022
@josharian
Copy link
Contributor Author

cc @ianlancetaylor as FYI / nudge :)

@ianlancetaylor
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants