spec, go/types, types2: restore Go 1.20 unification when compiling for Go 1.20

[vagruchi]

What version of Go are you using (go version)?

1.21.0

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

I can reproduce this issue using playground only

What did you do?

use code

// You can edit this code!
// Click here and start typing.
package main

import "fmt"

type GenericType[T any] interface{}

func get[T any](v GenericType[T]) {

}

func use() {
	var f GenericType[int]
	get(f)
}

func main() {}

What did you expect to see?

no error as it is with go 1.20 https://go.dev/play/p/CEVB_qbwsPu?v=goprev

What did you see instead?

error ./prog.go:13:5: cannot infer T (prog.go:7:10) https://go.dev/play/p/CEVB_qbwsPu

[seankhliao]

@ianlancetaylor @griesemer

[findleyr]

I believe this is a consequence of #60377.

[findleyr]

This is definitely a consequence of #60377. At the time, this was considered bug in the type inference algorithm that was inconsistent with looking inside the interfaces (per #41176).

CC @rsc for awareness.

[rsc]

It sounds like we should at least restore the old behavior when go.mod says "go 1.20".
Let's try to do that in the next point release.

[dmitshur]

The fix needs to land on the main branch first (i.e., where Go 1.2​2 development happens), and then it can be backported to release-branch.go1.21. I'll move this to Go1.2​2 milestone and create a backport issue to track the fix for Go 1.21.1.

@gopherbot Please backport to Go 1.21 with the rationale @rsc provided:

[...] we should at least restore the old behavior when go.mod says "go 1.2​0".
Let's try to do that in the next point release.

[gopherbot]

Backport issue(s) opened: #61930 (for 1.21).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[griesemer]

The 1.20 behavior was incorrect. For instance, taking the (slightly pared down, but equivalent) example from above:

package main

type T[P any] interface{}

func f[P any](T[P]) {}

func main() {
	var x T[int]
	f(x)
}

which works with Go1.20 but doesn't work with Go1.21 (because any arbitrary type argument would be acceptable for type parameter P and hence we can't infer a specific one), and now we add an extra parameter to f like so:

package main

type T[P any] interface{}

func f[P any](T[P], P) {}

func main() {
	var x T[int]
	var y string
	f(x, y)
}

Now this code doesn't work with Go1.20 because the inferred argument for P is wrong, but it works with Go1.21.

We can try to restore the incorrect behavior for 1.20, and it will "fix" this particular case, but it will also re-introduce a bug.

[gopherbot]

Change https://go.dev/cl/519855 mentions this issue: go/types, types2: disable interface inference for versions before Go 1.21

[rsc]

I wouldn't say that it introduces bugs so much as it preserves them, which is what compatibility tends to be all about. 😄
We've said from the start that if we had some kind of show-stopper bug in generics that needed fixing, the way we'd do that compatibly is to key the behavior off the Go language version. This is not a show-stopper but it came up in at least one person's real programs, so it's worth keeping the compatibility in old code.

[gopherbot]

Change https://go.dev/cl/520195 mentions this issue: Revert "go/types, types2: remove internal constant enableInterfaceInference"