A possibly minified repro (with struct { int }): https://go.dev/play/p/F_PIyGVxd0E.

Although both values have type struct { int }, in 1.18 the type descriptors for the two values are different. In 1.17 they are the same. This appears to be a bug in 1.18. I don't see any difference in the field values of the descriptors, we seem to just have two different identical descriptors.

CC @randall77 @cherrymui

@gopherbot Please open a backport for 1.18.

This should be fixed in a 1.18 minor release. The bug does not exist in earlier releases.

Backport issue(s) opened: #52858 (for 1.18).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

The spec says https://go.dev/ref/spec#Type_identity

Two struct types are identical if they have the same sequence of fields, and if corresponding fields have the same names, and identical types, and identical tags. Non-exported field names from different packages are always different.

Here the field name (int) is non-exported. I would think the new behavior is actually correct.

The embedding makes it an interesting case. I guess one could argue that the field name for both types is from the builtin package, therefore same? If it were non-embedded type (like struct { x int } or even struct { int int }), it would be clearly different, and the compiler always emits different type descriptors.

Thanks. You're right: with 1.18 the Field(0).StructField.PkgPath field is different for the two types. With 1.17 it's main for both.

I guess this may be technically correct. Anybody want to argue otherwise?

CC @griesemer @mdempsky

I agree the 1.18 behavior is correct. struct { int } denotes different types when it appears in different packages, because the field names are non-exported and therefore different.

FWIW, I suspect https://go-review.googlesource.com/c/go/+/378434/ is the CL that introduced the changed (fixed) behavior here.

I'd also say the 1.18 behavior is correct. The name of an embedded field is simply the (unqualified) name of the embedded type, there's no knowledge of that name coming from a built-in (predeclared) type. The usual export rules apply. The behavior for struct{int} should be the same as for struct{int int} with respect to DeepEqual.

Working as intended.

To finally clarify the question

If you replace the example with one like this, it is true everywhere.

func T() interface{} {
return struct{ X int }{123}
}

And if you replace the example with one like this, it is false everywhere.

type Q struct{ I int }

func T() interface{} {
return Q{123}
}

Is this behavior correct?

Two struct types are identical if they have the same sequence of fields, and if corresponding fields have the same names, and identical types, and identical tags. Non-exported field names from different packages are always different.

@mdempsky

@pfi79 The code at https://go.dev/play/p/aAwW6Hhyous appears to behaving correctly, yes.

Edit: To elaborate, defined types declared by different type declarations are always different, and reflect.DeepEqual documents that values of different types are always unequal.

Working as intended.

I have to say it's a little bit unexpected, while I understand why it should be true speaking of unexported fields, IMO with embedding, it is not that obvious, and breaking backwards compatibility.

@C0rWin I'm sorry for surprise.

Change https://go.dev/cl/414235 mentions this issue: test: add test that gofrontend gets wrong

Change https://go.dev/cl/414294 mentions this issue: compiler: use package path with embedded builtin type