As we focus on error messages, both in the type checker and in vet, I am becoming increasingly concerned that the type parameter type string is misleading.

For example, when running vet on the following code

package pkg

type U[P any] int

func (r U[P]) GobDecode(P) {}

We end up with diagnostics like this:

method GobDecode(pkg.P) should have signature GobDecode([]byte) error

In these cases the qualification of pkg.P is almost always misleading -- it looks like a named type.

I can think of several ways to proceed:

1. Do nothing.
2. Drop qualification altogether: a type parameter type string is just its name: GobDecode(P)
3. Capture the 'owning' object when binding a type parameter to a type: GobDecode(pkg.U.GobDecode.P) (assuming we associate with the method).
4. Use a special prefix or suffix to identify that something is a type parameter: GobDecode($P) (this is like (2) but unambiguous when using e.g. types.RelativeTo as a qualifier).

Type parameters only have meaning in the scope in which they are bound. For that reason, maybe it's sufficient for their type string to just be their name, as in option (2). Option 3 is precise, but verbose. I like the look of option 4, but it is rather risky.

CC @griesemer @mdempsky