Closed jay-babu closed 1 year ago
Hmm,
It's certainly not a bad idea...but I do think people mostly will start with a Set from the get-go if they do need a set. There could be some underlying oddities trying to handle the copy code for the end-user. Shallow copy vs deep copy comes to mind.
If this library were to take it on, it would only make sense to accept comparable
types, ie. anything that is guaranteed to be comparable.
Give me a bit to think about this use case and thanks for your interest in improving this library.
Anyone else have opinions on supporting this?
Sure, up to you
The code is pretty simple (ignoring deep copies):
func NewSetFromMapKey[T comparable, V any](vals map[T]V) mapset.Set[T] {
s := mapset.NewSet[T]()
for k := range vals {
s.Add(k)
}
return s
}
For now, I'll keep it to myself lol
If you’re up for writing the code with appropriate unit tests…let’s do it!
sure, let me fork and give it a shot
I'm curious what scenarios you end up creating a set of map keys? If you've already got a map, you've effectively got a superset of the normal set functionality... in fact, the idiomatic way to create go sets without this library is a map of empty structs. So why extract the keys and convert to a set?
I'm curious what scenarios you end up creating a set of map keys? If you've already got a map, you've effectively got a superset of the normal set functionality... in fact, the idiomatic way to create go sets without this library is a map of empty structs. So why extract the keys and convert to a set?
I had a set from some other logic and a map. I needed to find the intersection of the set and map keys. can't go into deep details
Hello,
I was wondering what your thoughts were on adding a func to create a Set from Map
mapset.NewSetFromMapKey[T](map[T]any)
mapset.NewSetFromMapValue[T](map[any]T)
I find myself doing this often. Thought others might as well