Parametric Methods

## Two different things that both look "generic" Go has had type parameters since 1.18, but until Go 1.27 they could appear in only two places: on a function declaration and on a type declaration. A method declaration could *use* type parameters, but only ones it inherited from its receiver type. Go 1.27 added a third place: a method may now declare a type parameter list of its own. ### A method on a generic type ```go type Framer[T any] struct{ frames []T } func (f *Framer[T]) Add(v T) { f.frames = append(f.frames, v) } ``` The `[T]` in the receiver `(f *Framer[T])` is not a new declaration in the sense of introducing freedom — it binds a name to the type argument the receiver was created with. If you build a `Framer[Frame]`, then for that value `T` *is* `Frame`, permanently, in every method. `Add` cannot be called with anything else, and two calls on the same value always use the same `T`. This shape has been legal since generics landed in 1.18. ### A method with its own type parameter ```go type Adapter struct{ topic string } func (a Adapter) Decode[F any](frame []byte) (F, error) { var out F err := json.Unmarshal(frame, &out) return out, err } ``` Here `F` is declared by `Decode` itself, between the method name and the parameter list. The receiver type `Adapter` is an ordinary, non-generic struct. Every call chooses its own `F`: one call site can decode into a `Heartbeat`, the next into a `Payload`, using the *same* `Adapter` value. That is what "parametric method" means, and in Go it is a Go 1.27 feature. ### What you wrote before 1.27 Before Go 1.27 the compiler rejected any method declaration that listed type parameters. The standard workaround was to hoist the operation out of the method set into a package-level generic function whose first argument is the value the method would have had as its receiver: ```go func DecodeFrame[F any](a Adapter, frame []byte) (F, error) ``` This is why so much idiomatic Go code exposes package-level functions where another language would expose methods — the standard library's slice and map helpers are functions, not methods, for exactly this reason. That workaround has not gone away and is still the right answer whenever the operation must remain reachable through an interface (see below). ### The restriction that comes with the feature Generic methods are deliberately limited in Go 1.27: - An **interface** may not declare a method with its own type parameters, in any Go version. Since a constraint is just an interface, a constraint cannot require one either. - A **generic method cannot implement an interface method**. A type that has one still satisfies interfaces through its *other* methods, but the parametric method itself never counts toward satisfaction. The reason is dispatch. An interface value carries a table with exactly one function pointer per interface method, filled in when the concrete type is assigned. A method whose type parameter is chosen at the call site has an open-ended family of instantiations, so there is no single entry to put in that table. ### How to tell them apart when reading code Look at where the brackets are: - Brackets in the **receiver** (`func (f *Framer[T]) Add(v T)`): the parameter belongs to the type. Fixed for the life of the value. - Brackets after the **method name** (`func (a Adapter) Decode[F any](...)`): the parameter belongs to the method. Chosen per call. Go 1.27 or later. - Brackets after a **function name** with no receiver (`func DecodeFrame[F any](a Adapter, ...)`): an ordinary generic function. ### Why it matters for API shape Moving a type parameter from the type onto the method changes who chooses it. On the type, the caller commits once, at construction, and everything downstream is fixed. On the method, the caller commits at each call and can use one value many ways. That flexibility is real, but it costs you interface satisfaction for that method — so if consumers of your package depend on an interface, the operation belongs in a package-level function or in a method with a concrete signature.