Go 1.18 won't have a '
constraints' package of generics helpers
If you read a number of writeups of the Go's new support for generics,
which is expected to be in Go 1.18, you'll find them mentioning a
constraints package in the standard library (for example, Generics
in Go). The
is there to give people a pre-defined set of names for various type
constraints, like 'only integer types'. Go itself defines two built
in constraints, '
any' (which allows anything) and '
(which allows anything that can be compared for equality); everything
else you either have to write yourself using type sets syntax or get from
Or at least that was the state of affairs until very recently, when
the Go developers decided that they didn't want to commit to the
constraints package this early in the use of generics. This was
discussed in issue #50792, constraints: move to x/exp for Go 1.18, filed by Russ Cox. To
quote from the start of that issue:
There are still questions about the the constraints package. To start with, although many people are happy with the name, many are not. On top of that, it is unclear exactly which interfaces are important and should be present and which should be not. More generally, all the considerations that led us to move slices and maps to x/exp apply to constraints as well.
As far as I know, the current version of x/exp/constraints is the same as what was in the Go development source tree until very recently.
On the whole I think this is a good change, because the Go developers
take their compatibility promises seriously. Once something is in
the Go standard library, its name and API is frozen, so getting
both of those right is important. And regardless of what we like
to think, people are not always great at either naming or APIs.
Sometimes it takes experimentation, actual use, and experience to
sort it out, and Go has already had issues with this (most famously
context, which was added to the
standard library after various APIs that really should take a Context
The negative side of this change is that it makes life a bit harder
and less obvious for people who want to do things with generics that
go beyond just a '
comparable' constraint. In turn this seems likely
to reduce the number of people doing this, which means that we'll get
less such experimentation and use of generics. By making it harder for
people to go beyond '
comparable', the Go developers may have made it
a self-fulfilling prophecy that people mostly don't. Perhaps this is a
good thing, if you want to minimize use of generics in general.
(I'm not sure that the Go developers genuinely like generics, as opposed to just accepting that they're necessary in some form.)
This does show that the Go developers can change their mind about things quite late, since this change comes after the second beta release of Go 1.18. The Go 1.18 version of generics won't really truly be finalized until Go 1.18 is officially released (although major changes seem unlikely at this point because of the amount of code changes that would be required for anything except perhaps disabling generics entirely).