Ian Lance Taylor
12 January 2021
We’ve filed a Go language change
proposal to add support for type
parameters for types and functions, permitting a form of generic
Generics can give us powerful building blocks that let us share code
and build programs more easily.
Generic programming means writing functions and data structures where
some types are left to be specified later.
For example, you can write a function that operates on a slice of some
arbitrary data type, where the actual data type is only specified when
the function is called.
Or, you can define a data structure that stores values of any type,
where the actual type to be stored is specified when you create an
instance of the data structure.
Since Go was first released in 2009, support for generics has been one
of the most commonly requested language features.
You can read more about why generics are useful in
an earlier blog post.
Although generics have clear use cases, fitting them cleanly into a
language like Go is a difficult task.
One of the first (flawed) attempts to add generics to
Go dates back
all the way to 2010.
There have been several others over the last decade.
For the last couple of years we’ve been working on a series of design
drafts that have culminated in a design based on type
This design draft has had a lot of input from the Go programming
community, and many people have experimented with it using the
generics playground described in an
earlier blog post.
Ian Lance Taylor gave a talk at GopherCon
about why to add generics and the strategy we are now following.
Robert Griesemer gave a follow-up talk about changes in the design,
and the implementation, at GopherCon
The language changes are fully backward compatible, so existing Go
programs will continue to work exactly as they do today.
We have reached the point where we think that the design draft is good
enough, and simple enough, to propose adding it to Go.
The language change proposal process
is how we make changes to the Go language.
We have now started this process
to add generics to a future version of Go.
We invite substantive criticisms and comments, but please try to avoid
repeating earlier comments, and please try to avoid simple plus-one
and minus-one comments.
Instead, add thumbs-up/thumbs-down emoji reactions to comments with
which you agree or disagree, or to the proposal as a whole.
As with all language change proposals, our goal is to drive toward a
consensus to either add generics to the language or let the proposal
We understand that for a change of this magnitude it will be
impossible to make everybody in the Go community happy, but we intend
to get to a decision that everybody is willing to accept.
If the proposal is accepted, our goal will be to have a complete,
though perhaps not fully optimized, implementation for people to try
by the end of the year, perhaps as part of the Go 1.18 betas.