Ian Lance Taylor and Robert Griesemer
16 June 2020
It’s been almost a year since we last wrote about the possibility of
adding generics to Go.
It’s time for an update.
We’ve been continuing to refine the generics design
We’ve written a type checker for it: a program that can parse Go code
that uses generics as described in the design draft and report any
We’ve written example code.
And we’ve collected feedback from many, many people—thanks for
Based on what we’ve learned, we’re releasing an updated design
The biggest change is that we are dropping the idea of contracts.
The difference between contracts and interface types was confusing, so
we’re eliminating that difference.
Type parameters are now constrained by interface types.
Interface types are now permitted to include type lists, though only
when used as constraints; in the previous design draft type lists were
a feature of contracts.
More complex cases will use a parameterized interface type.
We hope that people will find this design draft simpler and easier to
To help decide how to further refine the design draft, we are
releasing a translation tool.
This is a tool that permits people to type check and run code written
using the version of generics described in the design draft.
It works by translating generic code into ordinary Go code.
This translation process imposes some limitations, but we hope that it
will be good enough for people to get a feel for what generic Go code
might look like.
The real implementation of generics, if they are accepted into the
language, will work differently.
(We have only just begun to sketch out what a direct compiler
implementation would look like.)
The tool is available on a variant of the Go playground at
This playground works just like the usual Go playground, but it
supports generic code.
You can also build and use the tool yourself.
It is available in a branch of the master Go repo.
Follow the instructions on installing Go from
Where those instructions direct you to check out the latest release
tag, instead run git checkout dev.go2go.
Then build the Go toolchain as directed.
git checkout dev.go2go
The translation tool is documented in
We hope that the tool will give the Go community a chance to
experiment with generics.
There are two main things that we hope to learn.
First, does generic code make sense?
Does it feel like Go?
What surprises do people encounter?
Are the error messages useful?
Second, we know that many people have said that Go needs generics, but
we don’t necessarily know exactly what that means.
Does this draft design address the problem in a useful way?
If there is a problem that makes you think “I could solve this if Go
had generics,” can you solve the problem when using this tool?
We will use the feedback we gather from the Go community to decide how
to move forward.
If the draft design is well received and doesn’t need significant
changes, the next step would be a formal language change
To set expectations, if everybody is completely happy with the design
draft and it does not require any further adjustments, the earliest
that generics could be added to Go would be the Go 1.17 release,
scheduled for August 2021.
In reality, of course, there may be unforeseen problems, so this is an
optimistic timeline; we can’t make any definite prediction.
The best way to provide feedback for the language changes will be on
the mailing list firstname.lastname@example.org.
Mailing lists are imperfect, but they seem like our best option for
When writing about the design draft, please put [generics] at the
start of the Subject line and to start different threads for different
If you find bugs in the generics type checker or the translation tool,
they should be filed in the standard Go issue tracker at
Please start the issue title with cmd/go2go:.
Note that the issue tracker is not the best place to discuss changes
to the language, because it does not provide threading and it is not
well suited to lengthy conversations.
We look forward to your feedback.
We’re not finished, but we’ve come a long way.
We would not be here without a lot of help.
We’d like to thank Philip Wadler and his collaborators for thinking
formally about generics in Go and helping us clarify the theoretical
aspects of the design.
Their paper Featherweight Go
analyzes generics in a restricted version of Go, and they have
developed a prototype on GitHub.
We would also like to thank the
who provided detailed feedback on an earlier version of the design
And last but definitely not least, we’d like to thank many people on
the Go team, many contributors to the Go issue tracker, and everybody
else who shared ideas and feedback on earlier design drafts.
We read all of it, and we’re grateful. We wouldn’t be here without