Here's another example, which seems to have the opposite behavior. When a function is given as a type constraint, it's not inferred, but when it's declared as a parameter, it is inferred properly: https://go.dev/play/p/qOpMvvHt8On

package main

// FetchFunc is a function that is invoked when a cached value is not found.
type FetchFunc[V any] func() (V, error)

// Cache is a generic cache implementation.
type Cache[K comparable, V any] interface {
	Get(K)
	Set(K, V)
}

// LRU is a cache.
type LRU[K comparable, V any] struct{}

func (l *LRU[K, V]) Get(key K)        {}
func (l *LRU[K, V]) Set(key K, val V) {}

func Fetch1[K comparable, V any, C Cache[K, V]](cache C, key K, fn FetchFunc[V])      {}
func Fetch2[K comparable, V any](cache Cache[K, V], key K, fn FetchFunc[V])           {}
func Fetch3[K comparable, V any, C Cache[K, V], F FetchFunc[V]](cache C, key K, fn F) {}

func main() {
	var lru LRU[string, int]

	Fetch1(&lru, "foo", func() (int, error) { return 0, nil }) // ok

	Fetch2[string, int](&lru, "foo", func() (int, error) { return 0, nil }) // ok
	Fetch2(&lru, "foo", func() (int, error) { return 0, nil })              // nok: cannot infer K and V

	Fetch3(&lru, "foo", FetchFunc[int](func() (int, error) { return 0, nil })) // ok
	Fetch3(&lru, "foo", func() (int, error) { return 0, nil })                 // nok: does not implement FetchFunc[int]
}

These cases are in fact different. The only error message I see that looks clearly unhelpful is

	WithLocking2[string](&lru)      // nok: does not match Cache[string, V]

for which the full error is

foo.go:32:23: type *LRU[string, int] of &lru does not match Cache[string, V]

The other cases seem to be saying the right thing. It seems normal to me to get different kinds of errors based on different kinds of type inference. Maybe I'm missing something.

CC @griesemer

It would also be helpful to understand why the functions in this comment are all subtly different. I've read through all the generics documentation, and I think I'm missing something.

The error cases in the second comment can only work if the compiler uses the argument to infer the type arguments of the generic type of the parameter. There is no type inference rule that will do that. The type inference is as described at https://tip.golang.org/ref/spec#Type_inference. Rules that are not listed there are not applied, even if they may be obvious to the human reader.

I agree with @ianlancetaylor here. All these cases are slightly different and result in slightly different inference mechanisms, resulting to slightly different errors.

This is not to say that we cannot do better - improving inference and related error messages was simply not the highest priority so far.

With respect to "but there seems to be multiple ways to define generics, all of which are subtly different with unknown consequences" I respectfully disagree: there's exactly one way to define generic types and functions, by declaring type parameters and constraints. We allow - as syntactic sugar - the leaving away of the interface wrapper around constraint types, which is about the only variation permitted.

But there are different ways to invoke/instantiate a generic function: with or without type inference, and when using type inference, with partial type argument lists.

Leaving this open for now, as a reference for when we work on better type inference and/or error messages.

Simplified code for the case that could use a better error message (playground link):

package main

type Cache[K comparable, V any] interface{}

type LRU[K comparable, V any] struct{}

func WithLocking2[K comparable, V any](Cache[K, V]) {}

func main() {
	WithLocking2[string](LRU[string, int]{})
}

At the moment the error is:

type LRU[string, int] of LRU[string, int]{} does not match Cache[string, V]

The reason it doesn't match is because LRU[string, int] and Cache[string, V] are different defined types (even after inferring V = int). Should make that clearer.

Change https://go.dev/cl/474197 mentions this issue: go/types, types2: clean up defined type identity check/unification

With the above CL, the error message for the above example is now:

type LRU[string, int] of LRU[string, int]{} does not match inferred type Cache[string, int] for Cache[string, V]

making it clearer that V got inferred to int, so it's LRU and Cache which don't match.

I like it.

The above CL has now landed. Given the variety of calls and type parameters, a variety of error messages is expected. The one that's been most confusing is fixed with the CL.

There's more opportunity for better error messages. Ok to file issues for such cases, ideally one issue per case.

Closing this as fixed for now.