Go's Collections Working Group Proposes Generic Sets, Maps, and Heaps for 1.28

A newly formed Go Collections working group — including longtime language stewards Robert Griesemer, Ian Lance Taylor, and Alan Donovan — is proposing to fill a long-standing gap in Go’s standard library: real collection data structures. Historically Go leaned on its built-in slices and maps and shipped little else, with heaps for priority queues being the main exception. Sets didn’t exist at all, forced into idioms like map[T]bool or map[T]struct{}, and ordered maps or tree-backed structures were absent entirely. The umbrella proposal targets Go 1.28 and bundles several concrete additions under the existing container tree, including hash-based and comparable-element sets, an ordered map backed by a balanced binary tree, helper functions for manipulating legacy sets, and a redesigned generic heap (heap/v2) meant to replace the notoriously awkward existing one.

The effort is only feasible because of two recent language milestones: generics (1.18) and iterators (1.23), which together let library-defined types approach the ergonomics of built-ins. A recurring technical wrinkle is the “binary method problem” — a Union method on set type S returns S, so different set implementations can’t share an ordinary interface. The group works around this with F-bounded (recursive) constraint interfaces, adding unexported abstract Collection, Set, and Map types that let implementors write generic helpers like Subset or Take across concrete collection types. For now these abstractions stay private, serving as documented conventions and test-conformance guarantees rather than public API.

The design deliberately favors pragmatism over completeness: initial implementations aim for correct APIs and expected asymptotic performance, leaving constant-factor optimization out of scope. There’s also acknowledged arbitrariness in which operations belong as interface methods versus free-standing generic functions, a tension the group illustrates with the Subset question. Notably, the team chose the word “collection” over “container” in framing to avoid confusion with Linux containerization, even as the packages live in the container tree. Additional proposals — insertion-ordered maps and stacks among them — are expected to follow.