Why can a Go interface never declare a method that has its own type parameter?

## The rule Two restrictions travel together, and they are both about the same thing: 1. An **interface type may not declare a method with its own type parameters**. `Decode[F any](frame []byte) (F, error)` inside an `interface { ... }` block is not valid Go, in any version, including Go 1.27 which introduced generic methods on concrete types. 2. A **generic method cannot implement an interface method**. If `Adapter.Decode` declares its own `F`, then `Adapter` does not satisfy an interface requiring a `Decode` method — the parametric method simply does not count. A type with a generic method is not shut out of interfaces entirely; its *other*, ordinary methods still satisfy whatever they satisfy. It is that one method that cannot participate. ## Why: what an interface value actually is At run time an interface value is a pair: a pointer to the dynamic value and a pointer to a table describing its concrete type. That table contains one entry per method the interface requires, resolved when the concrete type is assigned into the interface. A call through an interface is an indirect jump to a fixed slot in that table. Now consider what a parametric method would need. `Decode[F any]` is not one function. The compiler produces code per type argument — sharing an implementation across type arguments with the same memory shape and passing a dictionary of type information — so `Decode[Heartbeat]` and `Decode[Payload]` do not resolve to the same entry point in general, and neither do the instantiations that some *other* package, compiled later, will ask for. There is no finite list of entries to build. The table cannot be constructed at the moment of assignment because the set of instantiations is not known then, and it is not known ever. ## Why: the signature does not exist There is a second, more basic problem, and you can see it without knowing anything about dispatch tables. An interface method has a *signature*: a fixed list of parameter and result types. What is the result type of `Decode[F any](frame []byte) (F, error)`? It depends on `F`, which the caller supplies. Nothing about the interface can state "returns whatever the caller asked for" — that is precisely the information an interface deliberately erases. Interfaces abstract over the concrete type on the *receiver* side. A method type parameter abstracts on the *caller* side. The two do not compose. This is why interfaces and generics in Go are described as complementary rather than alternative: subtype abstraction hides the implementation from the caller, parametric abstraction hides the caller's type from the implementation, and one method cannot do both. ## Constraints inherit the restriction A generic constraint is written as an interface, so everything above applies to constraints too. You cannot write a constraint saying "any type that has a `Decode` method with its own type parameter". A constraint can require an ordinary method, and it can require a type set, but it cannot demand parametricity from its members. This matters when you sketch an API and reach for "I will just require a generic method on the constraint". You cannot; the operation has to become a package-level generic function that takes the value as an argument, and the constraint then requires whatever ordinary methods that function needs. ## What this looks like in practice Suppose you write an adapter that turns another team's wire frames into your own structs, and you want callers to name the target type at each call. The natural instinct is: ```go type Decoder interface { Decode[F any](frame []byte) (F, error) // not valid Go } ``` The compiler rejects the interface itself. The alternatives, in rough order of preference: - **A package-level generic function.** `func DecodeFrame[F any](a Adapter, frame []byte) (F, error)`. Callers name `F`, or let inference find it from an argument. Nothing is hidden behind an interface, which is usually fine. - **A generic type instead of a generic method.** `type Decoder[F any] interface { Decode(frame []byte) (F, error) }` is perfectly legal: the parameter is on the interface *type*, so once instantiated as `Decoder[Heartbeat]` the method signature is fixed and dispatch works normally. The cost is that the caller commits to `F` when it obtains the interface value, not at each call. - **A concrete signature.** Have the method return a defined struct, or `any`, or write into a caller-supplied pointer: `Decode(frame []byte, into any) error`. This is what `encoding/json` does with `json.Unmarshal`, and it trades compile-time typing for a run-time reflection step. The second option is the one people miss. "Interfaces cannot have generic methods" does not mean "interfaces and generics do not mix" — a parameterised *interface type* is ordinary and useful. It is only the per-call, per-method parameter that dispatch cannot carry.