CC @golang/compiler.

struct{string} denotes different types when it appears in different packages. So failing to type check is the correct behavior here.

Agreed the error message is unfortunate for not being able to disambiguate that though.

/cc @griesemer @findleyr

Ack, this is unfortunate and confusing. It would be good to clarify that the identity of the string field does not match here.

I am not sure how high a priority this is, but we do want to continue to improve error messages in the new type checker. (I have not yet checked whether the old type checker produced a better message here).

@findleyr As part of triage assigning to you for now, but please feel free to unassign! Noted the low-ish priority.

Reassigning to @dr2chase who volunteered to take a quick look.

The new type checker is annoying in its parsimony; structs, which can have packages as part of their identity, don't know their own packages. The old type checker was similarly confusing.

I have a maybe fix, subject to passing tests. I'm not proud of it....

structs, which can have packages as part of their identity, don't know their own packages

Named structs you can find their package with Named.Obj().Pkg().

Anonymous, non-empty structs you can find their package with Struct.Field(0).Pkg(). (A struct definition can't span multiple packages, so all of its fields must exist in the same package.)

The anonymous, empty struct is identical in all packages.

The new type checker is annoying in its parsimony; structs, which can have packages as part of their identity, don't know their own packages.

Struct fields are objects, which have access to their package.

To expand: this rule is implemented in types.identical, the call to sameId for struct fields.

To implement this, we'd probably need to pass a reason *string argument into types.identical, similarly to what we do for other predicates. (aside, per the discovery in #54172, we should avoid building this reason if it won't be used).

Change https://go.dev/cl/422914 mentions this issue: cmd/compile: package-annotate structs when error would be ambiguous

Simplified reducer, for use as test case, and for the benefit of other readers:

// file a.go
package a

type S struct{}

func (S) M() (_ struct{ f string }) {
	return
}

package b

import "./a"

type I interface {
	M() (_ struct{ f string })
}

var _ I = a.S{}

Similar to the original, the error message is:

b.go:9:11: cannot use a.S{} (value of type a.S) as type I in variable declaration:
	a.S does not implement I (wrong type for M method)
		have M() (_ struct{f string})
		want M() (_ struct{f string})

The code compiles if the field f is exported (capitalized) in both files. The "field name" for an embedded type (string in the original code) is the type name (string), which happens to be lower-case and thus not exported. Not exported names from different packages are always different.

As stated before, the compiler is correct to reject this code.

Change https://go.dev/cl/452455 mentions this issue: go/types, types2: better variable names, cleanups in test