compile: Regression in generics

[av86743]

Go version

Works in 1.20.14, b0rken after 1.21.13

Output of go env in your module/workspace:

Whatever playground settings are.

What did you do?

Playground example is here.

package main

type Parser_T[a_T any] interface{}

func Base_many_6f5dd[_84T any]( /* enlhd */
	_11 Parser_T[_84T]) /* rv: */ Parser_T[_84T] {
	/* returning LazyT[Parser_T[ LazyT[ListT[ _84T ]] ]] */
	//{
	_ = Base_many_6f5dd(_11)
	panic("")
}

func main() {}

Don't bother to lecture me how "you" could "fix" this in "your" code. Those who will, better first verify how this works with reference implementation of generics.

What did you see happen?

Compilation dies with diagnostics:

./prog.go:9:21: in call to Base_many_6f5dd, cannot infer _84T (declared at ./prog.go:5:22)

Bisected using Docker golang:1.xx.yy-alpine images to fail since 1.21.13.

What did you expect to see?

Works as in original early version.

[seankhliao]

I believe allowing it was a bug, see #60377

[gabyhelp]

Related Issues

• spec, go/types, types2: restore Go 1.20 unification when compiling for Go 1.20 #61903 (closed)
• go build generics backwards compatibility #61850 (closed)
• generics: a type declarations inside generic functions in some cases is not reported in the error report #50726 (closed)
• cmd/compile: //go:build file version ignored when calling generic fn which has related type params (reproduces with 1.21 and 1.20, not at tip) #64759 (closed)
• go/types, types2: generic type inference - generic interface input parameter of generic function #62612 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[av86743]

@seankhliao Have you even looked at the sample code? Whatever was being "fixed" in #60377, has conveniently broken it. Effectively, you are now forcing users do completely unnecessary manual work, instead of allowing compiler correctly do this routine job for them as it was doing before.

The only complaints you keep getting now are that "it stopped working." There are no complaints whatsoever that it works incorrectly, or at least counter-intuitively. Entire justification of the change is based on someone's blabber that "something somewhere might go wrong..." What kind of decision making is this?

[zigo101]

Custom generics introduce significant complexity, often outweighing their limited practical benefits.