Thanks @seankhliao!

That would make it difficult to write code like

type Zero[T any] struct{}
func (Zero[T]) Get() T {
    var zero T
    return zero
}

That's a fairly simple version but one can imagine more complicated ones.

For functions, it's possible to imagine having a family of functions that all share the same type parameters, even if they don't all use them.

Giving an error for unused local variables is helpful because they normally indicate a bug in the program. That is less clear for unused type parameters.

Thanks for the quick reply @ianlancetaylor!

For functions, it's possible to imagine having a family of functions that all share the same type parameters, even if they don't all use them.

That makes sense. I can see that it would be annoying to get an error from vet in such cases. And as you say, there's probably other scenarios where reporting an error would have a negative effect.

I don't quite see how the example you posted with a type is the same kind as with the function example above. You don't have to, of course, but could you explain why this is similar? I would think that there are no unused type parameters in the method Get(), since T is used as a return type.
I admit I haven't spent time trying out generic types yet, so that might be why I don't see it.

As for this issue, I was probably too quick! I'm fine with this being closed.

I think in the spirit of the suggestion for named types with methods, the vet check would likely require checking if the type parameter type is used in the underlying type or within any method for the named type.

type N[T any} struct {
  x T
}

AFAICT a pattern this does rule out is to use generic functions for type assertions for tilde and bar types.

type S int

func (S) Bar() {}
func f[T interface {
	Bar()
	~int | ~string
}]() {
}
func _() {
	f[S]()
}

Seems somewhat reasonable?

This proposal seems analogous to reporting unused function arguments, which we also don't do today.

I don't think we should report on unused type parameters going forward, either. It may be that the implementation of a struct or function initially depends on all of its type parameters but is then refactored such that one or more of the parameters is no longer needed. However, the extra parameter cannot be removed without breaking compatibility: existing users may already instantiate it explicitly.

This seems like a fine check for more aggressive linters, but I think the false-positive rate will be too high in the long run for cmd/vet.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group