On: The Next Step for Generics

[djhworld]

Neat, thrown together Set implementation https://go2goplay.golang.org/p/FffAhV8aLyN

[coder543 → djhworld]

Might as well use the zero-size struct{} instead of bool, given that you’re not currently using the bool values for anything: https://go2goplay.golang.org/p/9iegVQ2VQCr

Alternatively, use the bool values and rely on the zero value for missing elements: https://go2goplay.golang.org/p/E7yHQqAPseG

[bradfitz → coder543]

And variadic args to NewSet looks a bit nicer yet at the call site: https://go2goplay.golang.org/p/fTp3W9IwuVP

[parhamn → bradfitz]

Is there a way to do this without losing range?

[coder543 → parhamn]

The proposal is, for better or worse, quite clear about not providing operator overloading or anything similar in the near future.

You could always offer a method that returns a slice of unique elements, which could then be ranged over.

[djur → coder543]

I don't think there's nearly as much of an appetite for operator overloading as there is for an iterator protocol for range. That isn't to say that the latter wouldn't have a lot to argue over (internal vs. external, etc.) but I think the general usefulness of such a thing would be widely accepted by the community once generics are a settled matter, while I doubt that will ever happen for operator overloading.

[rogpeppe1 → djhworld]

I'm not sure that hiding the implementation is worth it here. Why not just make it public that it's actually map[T]struct{} underneath - then anyone can range on it and implement allocation optimisations, etc? I added some other methods too for the crack https://go2goplay.golang.org/p/EI1hYaSohnc