Go Proposes Generic Methods, Breaking Long-Held Stance Against Them

A new Go language proposal would allow concrete methods to declare their own type parameters, reversing a position the Go team has held since generics landed. The FAQ has long stated that Go would never add generic methods, because permitting them on concrete types was assumed to require supporting them on interfaces too — and nobody had a workable plan to implement generic interface dispatch efficiently given Go’s structural typing.

The proposal reframes the problem: concrete methods are useful for code organization and method-chaining ergonomics independent of interfaces, so generic concrete methods can be permitted while generic interface methods remain off the table. A generic method simply won’t satisfy any interface, since interface method syntax can’t carry matching type parameters. Syntactically, method declarations gain an optional type parameter list after the method name, and type arguments move from operand syntax into primary expressions to allow instantiation on arbitrary receiver expressions.

Two earlier community proposals (#49085 from 2021 and #50981 from 2022) racked up significant support, and this change addresses them without solving the harder interface-dispatch problem. Reflection still won’t expose generic methods, mirroring the existing limitation on uninstantiated generic functions.