spec: type inference doesn't work for struct literals

[fakke]

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

$ go version
go version go1.18beta1 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="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="~/Library/Caches/go-build"
GOENV="~/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="~/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="~/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="~/sdk/go1.18beta1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="~/sdk/go1.18beta1/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18beta1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m4/5y8kv34x7hn27crxq3cgwmrh0000gn/T/go-build3708845374=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

type A[T any] struct {
	t T
}

func main() {
	a := A{t: 0}
	print(a.t)
}

What did you expect to see?

0

What did you see instead?

cannot use generic type A[T any] without instantiation

[ianlancetaylor]

This kind of type inference is not supported at present. The only supported type inference is described at https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-inference.

(As we approach the 1.18 release please don't file a bunch of different issues about different kinds of type inference. That isn't going to help us. We are't going to add any more kinds of type inference for 1.18. Thanks.)

[beoran]

Again, this can be worked around easily by creating a generic MakeA function like this:
https://gotipplay.golang.org/p/6lpwTsit8Qf

Seeing that there are easy workarounds for this, i think we do not need any extra inference rules for this (or for the other similar issue).

[fakke]

thanks. i understand that this is a very minor feature, hope this will be implemented somewhere in the future