/cc @golang/compiler

(attn @griesemer)

This was a bug that was fixed for Go 1.21. The type parameter T of Foo is not used anywhere in Foo and thus one could infer an arbitrary type (or in this case either int or uint) and it would work.

More concretely, here's a slightly modified version of your example: checkMatch takes an extra argument of type T, and the call passes a uint argument y. The rest of the code is unchanged.

func main() {
	var v Foo[int]
	var y uint
	checkMatch(v, y)
}

func checkMatch[T Integer](v Foo[T], s T) {}

This code correctly infers uint for T in Go 1.21, but if fails in Go 1.20 because inference incorrectly infers int from the Foo[int] argument v which then conflicts with the uint inferred from the uint argument y.

For the original discussion see #60377.

Closing as working as intended.

Right, I see.

Apart from the assert, I used the type parameter to instantiate the right version of whatever was using v. This was quite useful. But now it seems I actually need to use the type somewhere in Foo[T].

My specific use case was a method on Foo (actually called Displayer) that accepts an image buffer in a particular format. Because the concrete type was written before generics, the parameter is basically just a raw byte buffer. So by calling a generic function with a Displayer[T] type where T was the pixel format, it can create the byte buffer in the requested format to pass to that method.

Here is a simplified version of what I'm doing: https://go.dev/play/p/PXuOVTqWMmZ
It compiles in Go 1.20, but doesn't compile in Go 1.21.

Anyway, I guess I'll have to add methods with the actual requested type (basically, giving the parameter to Update a type). It is a regression for my particular use case, but I can fix my code. I was probably not using generics as intended here.

As you say, you could add a dummy method (playground).
We understood only after 1.18 that inference must not infer a type if there is more than one possible choice because if can lead to inference failure when it clearly should succeed.

(I suppose one could try to make it work for both cases, but that would probably be complicated to explain.)