proposal: container/set: new package to provide a generic set type (discussion) #47331
Replies: 45 comments 352 replies
-
Needs some sort of performance promise. I think it would be ok to promise that |
Beta Was this translation helpful? Give feedback.
-
Regarding the naming, it seems inconsistent to me to have standalone functions named |
Beta Was this translation helpful? Give feedback.
-
I don't understand this argument (also, IMO there should just be one function |
Beta Was this translation helpful? Give feedback.
-
I find it awkward to say "Like maps, Sets are reference types" and having to explain that, instead of just making it a pointer. It might feel weird to always have to pass around a |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
Any reason why Union, Intersection and Difference are functions instead of methods? image.Rectangle has Union, Intersect and other binary operations as methods, image.Point and the types in math/big as well. Methods would feel more like infix notation. My suggestion would be Set[Elem].Union, Set[Elem].Intersect, Set[Elem].Diff |
Beta Was this translation helpful? Give feedback.
-
Why the requirement not to modify the set during iteration? Maps don't have that requirement and that's a very helpful property. Also, iterating by using a function is awkward (you can't just return from the outer function, or break more than one level of loop), so I wonder if it might be nicer to support some kind of iterator so iteration can be done with a straightforward |
Beta Was this translation helpful? Give feedback.
-
"Len" is an unusual name for the cardinality of a set, the colloquial term is usually "Size". Of course, "Len" would fit the Len method in sort.Interface (but the proposed Set type can't be sorted), and other types are measured via the "len" builtin function, so that's probably where it comes from. |
Beta Was this translation helpful? Give feedback.
-
Can we get explicit promises for the iteration order? And maybe another |
Beta Was this translation helpful? Give feedback.
-
Making |
Beta Was this translation helpful? Give feedback.
-
I would expect |
Beta Was this translation helpful? Give feedback.
-
This proposal uses |
Beta Was this translation helpful? Give feedback.
This comment has been minimized.
This comment has been minimized.
-
In functional programming, Personally, I like |
Beta Was this translation helpful? Give feedback.
-
Parallel to #47330 (comment) for |
Beta Was this translation helpful? Give feedback.
-
In Java, it is often annoying that the various container types' |
Beta Was this translation helpful? Give feedback.
-
I think the doc comment can be reduced to:
Calling sets "reference types" is confusing because they're not, at least as currently documented. They're just structs that happen to hold pointers, which is true of most Go types. We don't refer to them all as reference types. Calling out that Sets cannot be modified concurrently from multiple goroutines is also confusing, because that's the default expectation for every Go data structure. We only document the deviations, when concurrent modifications are allowed. (Compare list.List: it is just as much a "reference type" and is similarly safe to read but unsafe to modify from multiple goroutines, but we don't call attention to any of that. Or bytes.Buffer, which is also just as much a "reference type".) Mentioning maps also encourages the reader to start thinking about questions like why isn't this a map or exactly how maps work. It is probably better to just let Sets be Sets. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
The type Set[Elem comparable] struct {
// contains filtered or unexported fields
}
// Values returns the elements in the set s as a slice.
// The values will be in an indeterminate order.
func (s *Set[Elem]) Values() []Elem
// Do calls f on every element in the set s,
// stopping if f returns false.
// f should not change s.
// f will be called on values in an indeterminate order.
func (s *Set[Elem]) Do(f func(Elem) bool) I see two approaches to iteration given the current API:
Could we include in this proposal a method of iterating |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
This is a discussion that is intended to turn into a proposal.
This proposal is for use with #43651. We propose defining a new package, container/set, that will introduce a new set type.
It is possible that this proposal, if accepted, will be included with the first release of Go that implements #43651 (we currently expect that that will be Go 1.18). Or it may be appropriate to delay this package until a later release.This package will not be in the 1.18 release, but is for consideration for a later release.This description below is focused on the API, not the implementation. In general the implementation will be straightforward.
See also the slices proposal at #45955 (discussion at #47203) and the maps proposal discussion at #47330.
Beta Was this translation helpful? Give feedback.
All reactions