cmd/compile: cannot use generic type without instantiation

[septemhill]

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

$ go version
go version go1.21.0 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output

$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users/septemlee/Library/Caches/go-build'
GOENV='/Users/septemlee/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/septemlee/.gvm/pkgsets/go1.21.0/global/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/septemlee/.gvm/pkgsets/go1.21.0/global'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/septemlee/.gvm/gos/go1.21.0'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/septemlee/.gvm/gos/go1.21.0/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.21.0'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/1t/2fzzpms929v28gr7b0mdqcrr0000gn/T/go-build1855045304=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

I expected that I don't need infer type here after #59338 and #58650 be implemented.
https://go.dev/play/p/EFLOb5SmpYe

What did you expect to see?

Compiling succeed. And it would print out value 3 on screen.

What did you see instead?

cannot use generic type FnArg2 without instantiation

[septemhill]

I guess it might related to #50285 (comment) and #61712 ?

[mknyszek]

CC @golang/compiler

[mdempsky]

Type inference only applies to generic functions. Generic types always require explicit type arguments.

/cc @griesemer @ianlancetaylor

[septemhill]

Thanks for @mdempsky reply. This thing is even more relevant to #61731