Go 언어 1.28 표준 라이브러리에 제네릭 컬렉션 타입 추가 제안

Uh oh! There was an error while loading. Please reload this page . golang / go Public Notifications You must be signed in to change notification settings Fork 19.2k Star 135k proposal: container/...: generic collection types #80590 New issue Copy link New issue Copy link Open Open proposal: container/...: generic collection types #80590 Copy link Labels Proposal Milestone Go1.28 Description adonovan opened on Jul 28, 2026 Issue body actions Background: The Go Collections working group was formed in late 2025 with the purpose of bringing common collection data structures to the standard library, guided by the familiar Go principles of pragmatism and simplicity. Alphabetically by last name, the group consists of Jonathan Amsterdam ( @jba ), Alan Donovan ( @adonovan ), Robert Griesemer ( @griesemer ), Daniel Martí ( @mvdan ), Roger Peppe ( @rogpeppe ), Keith Randall ( @khr ), and Ian Lance Taylor ( @ianlancetaylor ). We’ve now reached a point where we’re ready to share our results with the community. This issue is an umbrella for discussing several related proposals for new collections APIs for Go 1.28. It presents a high level overview of the themes, and links to the various concrete proposals and associated implementation CLs. Go currently provides few collection types in its library, and from the outset we have emphasized the flexibility of the language’s built-in slice and map types. Of those provided, the most important is the heap, used for priority queues. Even sets are absent; they are conventionally expressed in terms of map[T]bool or map[T]struct{}. Ordered maps and sets based on binary trees are entirely absent. Since the addition of generics in Go 1.18 and iterators in Go 1.23, it has become possible for library-defined types to achieve comparable ergonomics to built-in types, and for many common operations on slices and maps to be expressed as calls to library functions. This work seeks to add several of the more important data types to the standard library, and to establish conventions for their APIs and those of future additions. Proposal: The proposed additions include: #70471 , CL 657296 (released in go1.27): hash/maphash.Hasher : a standard interface for expressing custom hash functions and equivalence relations for arbitrary data types. These may differ from the compiler-defined ones used by map[K]V, and are useful when the key type is not comparable (such as a slice or map), or when the default comparison yields the wrong result (such as for types.Type values, which need the deep comparison operation types.Identical ). Its package docs include an example of its use in a Bloom filter . #69559 , CL 612217 : container/hash.Map[K,V] : a hash-based Map that uses the custom hash functions mentioned above. #80584 , CL 741160 : container/hash.Set[T] : a hash-based Set along the same lines. #69230 , CL 745441 : container/set.Set[T] : a canonical data type for sets whose elements are comparable. It is transparently represented as map[T]struct{} and supports all the usual set operations such as Union and Intersection. It is more convenient than “legacy” sets based on map[T]bool and map[T]struct{}, and avoids ambiguity about potential false values in a map[T]bool. We expect it to become the standard set in most new Go APIs. #77052 , CL 724420 : container/mapset : a package of helper functions (Union, Intersection, and so on) for conveniently manipulating legacy sets as sets in existing code whose API cannot be changed. These functions are exactly parallel to the methods of set.Set. #60630 : container/ordered.Map[K,V] : an ordered mapping. The current implementation uses a balanced binary tree, but nothing in the design requires that. The common Go pattern of building a map[K]V then sorting its keys performs well in most cases, but on occasion, such as when a range query is needed, other data structures perform much better. #77397 : container/heap/v2.Heap : a generic binary heap API to replace the standard library's existing heap, which can be difficult to use. We expect to consider additional proposals in due course, such as insertion-ordered hash maps ( #80194 ) and stacks . The initial implementations of all the proposed data structures aim to satisfy the API and asymptotic performance expectations as simply as possible. There are doubtless many opportunities for later optimizations to reduce constant factors, but they are out of scope of the proposal process. Though the new packages will live in the existing container tree, we prefer the term “collection” to avoid confusion with the container virtualization concept from Linux. Abstract collection constraint interfaces Most of the methods of the new Map and Set types are not particular to any concrete representation type, but are common across all Maps and Sets. However, they are not really implementions of a common interface type because of the “ binary method problem ”: if each set data type S has a Union method of the form func (S) Union(S) S , then the Union methods of different set types are incompatible, so they have no common ordinary interface. To express this abstract Set type, we must use F-bounded polymorphism , or recursive constraint interfaces. CL 761460 adds to the container package unexported abstract Collection, Set, and Map constraint interface types that permit package implementors to write abstract helper functions (such as ContainsAny, Subset, or Arbitrary) that work across a range of concrete collection, set or map types. We reproduce these interfaces below, with some brief commentary, to help give a high-level picture but they are not part of any proposal . They merely serve to guarantee conformance in tests. See the individual proposals for more detail. // _AbstractCollection models a collection C of elements E, // such as *hash.Map, *hash.Set, *ordered.Map, or set.Set. type _AbstractCollection [ E any , C _AbstractCollection [ E , C ]] interface { Clear () Clone () C Contains ( E ) bool ContainsAll (iter. Seq [ E ]) bool Len () int String () string } // _AbstractMap models a mapping M from keys K to values V, // such as *hash.Map or *ordered.Map. type _AbstractMap [ K , V any , M _AbstractMap [ K , V , M ]] interface { _AbstractCollection [ K , M ] All () iter. Seq2 [ K , V ] At ( K ) V Delete ( K ) ( V , bool ) DeleteAll (iter. Seq [ K ]) bool DeleteFunc ( func ( K , V ) bool ) bool Get ( K ) ( V , bool ) Keys () iter. Seq [ K ] Set ( K , V ) ( V , bool ) SetAll (iter. Seq2 [ K , V ]) bool Values () iter. Seq [ V ] } // _AbstractSet models a set S of elements E, // such as *hash.Set, or set.Set. type _AbstractSet [ E any , S _AbstractSet [ E , S ]] interface { _AbstractCollection [ E , S ] All () iter. Seq [ E ] Delete ( E ) bool DeleteAll (iter. Seq [ E ]) bool DeleteFunc ( func ( E ) bool ) bool Difference ( S ) S DifferenceWith ( S ) Equal ( S ) bool Insert ( E ) bool InsertAll (iter. Seq [ E ]) bool Intersection ( S ) S IntersectionWith ( S ) Intersects ( S ) bool SymmetricDifference ( S ) S SymmetricDifferenceWith ( S ) Union ( S ) S UnionWith ( S ) } For now these abstract types are non-exported and merely serve as documentation of Go’s conventions to help ensure consistency. We do not propose to publish them yet, but may do so a later release after gaining experience with the concrete collection types. In the meantime, users can define minimal constraint types as needed, as in this example (from CL 761460 ) of a generic Take function over abstract sets: // _TakeSet defines an abstraction of a set sufficient for the [Take] function. type _TakeSet [ E any , S _TakeSet [ E , S ]] interface { All () iter. Seq [ E ] Delete ( E ) bool } // Take removes and returns an arbitrary element from a set. // It returns zero if the set was empty. func Take [ S _TakeSet [ E , S ], E any ]( set S ) ( e E , found bool ) { for e = range set . All () { found = true set . Delete ( e ) break } return } There is a certain arbitrariness to the set of methods included in each interfac