Emphasize the update.
1 file changed
tree: efde4c67f6d68ea7bbb2150c3176c04501bd0fce
  1. .gitignore
  2. .travis.yml
  4. README.md
  5. set.go
  6. set_test.go

Build Status GoDoc


A simple set type for the Go language. Until Go has sets built-in like maps, slices, and channels...use this.

Coming from Python one of the things I miss is the superbly wonderful set collection. This is my attempt to mimic the primary features of the set from Python. You can of course argue that there is no need for a set in Go, otherwise the creators would have added one to the standard library. To those I say simply ignore this repository and carry-on and to the rest that find this useful please contribute in helping me make it better by:

  • Helping to make more idiomatic improvements to the code.
  • Helping to increase the performance of it. (So far, no attempt has been made, but since it uses a map internally, I expect it to be mostly performant.)
  • Helping to make the unit-tests more robust and kick-ass.
  • Helping to fill in the documentation.
  • Simply offering feedback and suggestions. (Positive, constructive feedback is appreciated.)

I have to give some credit for helping seed the idea with this post on stackoverflow.

Update - as of 3/9/2014, you can use a compile-time generic version of this package in the gen framework. This framework allows you to use the golang-set in a completely generic and type-safe way by allowing you to generate a supporting .go file based on your custom types.

Please see the unit test file for additional usage examples. The Python set documentation will also do a better job than I can of explaining how a set typically works. Please keep in mind however that the Python set is a built-in type and supports additional features and syntax that make it awesome. This set for Go is nowhere near as comprehensive as the Python set also, this set has not been battle-tested or used in production. Also, this set is not goroutine safe. The rationale for this is the same reasons that the built-in maps and slices are not thread-safe. Performance is favored over synchronization because this largely depends on your application requirements. If you need synchronization, perhaps use a channels for a high-level solution or use mutex and embedding for a more low-level solution.

Examples but not exhaustive:

requiredClasses := NewSet()

scienceSlice := []interface{}{"Biology", "Chemistry"}
scienceClasses := NewSetFromSlice(scienceSlice)

electiveClasses := NewSet()

bonusClasses := NewSet()
bonusClasses.Add("Go Programming")
bonusClasses.Add("Python Programming")

//Show me all the available classes I can take
allClasses := requiredClasses.Union(scienceClasses).Union(electiveClasses).Union(bonusClasses)
fmt.Println(allClasses) //Set{Cooking, English, Math, Chemistry, Welding, Biology, Music, Automotive, Go Programming, Python Programming}

//Is cooking considered a science class?
fmt.Println(scienceClasses.Contains("Cooking")) //false

//Show me all classes that are not science classes, since I hate science.
fmt.Println(allClasses.Difference(scienceClasses)) //Set{Music, Automotive, Go Programming, Python Programming, Cooking, English, Math, Welding}

//Which science classes are also required classes?
fmt.Println(scienceClasses.Intersect(requiredClasses)) //Set{Biology}

//How many bonus classes do you offer?
fmt.Println(bonusClasses.Size()) //2

//Do you have the following classes? Welding, Automotive and English?
fmt.Println(allClasses.ContainsAll("Welding", "Automotive", "English")) //true



Bitdeli Badge