After Four Years of Go Generics, Generic Methods Are Finally Arriving

Background and the Long‑standing "Gap"

When Go 1.18 first brought generics, developers quickly noticed an asymmetry: generic functions and generic types were allowed, but generic methods were not. This limitation forced developers to break chainable calls and use top‑level functions instead of method syntax.

// Generic function: OK
func Print[T any](s []T) { ... }

// Generic type: OK
type List[T any] struct { ... }

// Generic method (currently errors!)
func (l *List[T]) Map[R any](f func(T) R) []R { ... }

The restriction stemmed from Go’s interface‑centric design. Methods were primarily seen as a way to implement interfaces, and allowing generic methods on structs would logically require generic methods in interfaces, which is extremely hard to support due to Go’s structural typing and the need for runtime code generation.

"Perhaps we need to change our view: concrete methods are a useful language feature that can exist independently of interfaces." – Robert Griesemer

Conceptual Shift – Untying Methods from Interfaces

The proposal (issue 77273) defines two terms:

Concrete Method : a method with a receiver that belongs to a concrete type (e.g., a struct).

Interface Method : a method signature declared inside an interface type.

By recognizing that concrete methods do not have to be tied to interface implementation, the Go team opened the door to generic methods on concrete types while still forbidding them on interfaces.

Proposal Details – Syntax and Rules

1. Declaration Syntax

The current method declaration is func Receiver MethodName Signature. The proposal changes it to:

func Receiver MethodName[TypeParameters] Signature

Example:

type S struct { ... }
// Define a generic method m with type parameter P
func (s *S) m[P any](x P) { ... }

Receivers themselves can be generic:

type G[P any] struct { ... }
func (g *G[P]) m[Q any](x Q) { ... }

2. Call Syntax

Calling a generic method mirrors calling a generic function. Both explicit instantiation and type inference are supported:

var s S
// Explicit type argument
s.m[int](42)
// Inferred type argument
s.m(42)

3. Method Expressions

Generic methods can be extracted as function values:

type List[E any] struct { ... }
func (l *List[E]) Format[F any](e E, f F) string { ... }

// Instantiate List[string] and extract Format
f := List[string].Format
// f has signature: func[F any](l *List[string], e string, val F) string

Note that the receiver type must be instantiated first; the method’s own type parameters can be supplied later.

Impact and Limitations

What We Gain

Fluent APIs: operations like filter, map, reduce can now be methods on slice‑wrapper types.

Better code organization: generic logic can live inside types instead of top‑level functions.

Potential standard‑library evolution: packages such as math/rand/v2 could expose methods like r.N[int](10) instead of separate generic functions.

What Remains Missing

Interfaces still cannot declare generic methods.

Even if a generic method’s instantiated signature matches an interface method, it does not satisfy the interface.

The reflect package cannot discover or invoke generic methods unless they are already instantiated.

Community Reaction and Future Outlook

The proposal sparked strong responses. Most developers welcomed the feature as the long‑awaited missing piece of Go’s generics puzzle, while some expressed concern that it could raise the learning curve for newcomers.

If approved, the change is expected to land in Go 1.27 (possibly first as a GOEXPERIMENT flag). Tooling such as gopls and go/types will need substantial updates to handle generic methods.

Conclusion – Pragmatic Evolution

Go’s journey from rejecting generics to embracing them, and now to decoupling concrete methods from interfaces, demonstrates a pragmatic philosophy: prioritize solving real‑world engineering pain points over theoretical symmetry. While interface generic methods remain absent, the addition of concrete generic methods opens a path to more expressive and elegant Go code.