cmd/compile: confusing error when trying to instantiate type parameter on other-package constraint with unexported fields

[ALTree]

Consider the following 3-files program:

go.mod:

module example.com/mod

go 1.18

a/a.go

package a

type I interface {
	struct{ i int }
}

func F[T I]() {}

test.go

package main

import "example.com/mod/a"

func main() {
	a.F[struct{ i int }]()
}

With go1.18 and tip, the program does not compile:

 $ go build
# example.com/mod
.\test.go:6:6: struct{i int} does not implement a.I

playground link: https://go.dev/play/p/yvRVxYbdkpK

To to me it looks like it should(?). The same constraint and function work fine when they're part of the main package. Am I missing something?

EDIT: I had the wrong mental model, it's correct that this doesn't work but the error message is slightly confusing. See below.

cc @findleyr @griesemer @mdempsky

[seankhliao]

This looks like visibility rules? exporting the struct field works: https://go.dev/play/p/S7_h3tqaeC7

[ALTree]

Mmh, indeed. If you change the signature to use an unnamed constraint, as: func F[T struct{ i int }]() {} the error message is quite puzzling:

./prog.go:6:6: struct{i int} does not implement struct{i int}

Leaving for others to decide if we can just close this, or if the error message should be tuned.

[seankhliao]

it's similar to the error without constraints: https://go.dev/play/p/E8rF0Rzw26_A

[mdempsky]

I think the type checker is correct to reject this code. struct{i int} denotes "different" types when appearing in different packages because of the non-exported field name.

That said, I agree the error message is confusing and could be made clearer like we do in some other cases.

[ALTree]

For some reason I had this mental model that for type parameters it didn't matter if the field was exported or not, so I expected to be able to resolve the correct instantiation of a.F by writing a.F[struct{ i int }]. Anyway clearly is not the case and of course a normal variable would not be assignable so it makes sense that it doesn't work for type parameters.

Retitling this to make it about a less confusing error.