cmd/compile: clarify prose/examples regarding struct identity when embedded types match equally named non-embedded fields

[leabit]

Go version

go version go1.23.0 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/leabit/.cache/go-build'
GOENV='/home/leabit/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/leabit/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/leabit/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/leabit/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.0.linux-amd64'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/leabit/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.0.linux-amd64/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.0'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/leabit/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/leabit/goprojects/exeexe/go.mod'
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 -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1849554432=/tmp/go-build -gno-record-gcc-switches'

What did you do?

Golang specification for type identity states the following for the struct types:

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.

Thus, it has 4 requirements:

1. same sequence of fields
2. same corresponding names
3. identical types of corresponding fields
4. identical tags of corresponding fields

However, there are cases related to embedding aliases of unnamed types where, despite meeting all four previous requirements, the compiler still fails to compile.

I will explain the problem through few examples. The following notes holds for all examples:

• three packages are used: pac1, pac2 and main
• declared alias types in pac and pac2 are unnamed types struct{} (thus, they are identical)
• struct tags aren't used, so they are ignored

(1) This example successfully compiles (as expected). M1 and M2 have the same sequence of fields. Names, even thought not explicitly defined, are indirectly given by embedding and thus they are same (MyType1). Types of the fields (field MyType1) are also same (struct{}).

pac1:

package pac1

type MyType1 = struct{}

pac2:

package pac2

type MyType1 = struct{}

main:

package main

import (
	"exeexe/pac1"
	"exeexe/pac2"
)

type M1 struct {
	pac1.MyType1
}

type M2 struct {
	pac2.MyType1
}

func main() {
	_ = M2(M1{})
}

(2) In this example MyType1 = struct{} is replaced with MyType2 = struct{} in pac2. Also, pac2.MyType2 is now embedded in M2 (instead of pac2.MyType1) in main package. As expected, it doesn't compile. Even thought the types of the fields are the same, the names are not (MyType1 != MyType2), thus requirement 2 doesn't hold.

pac1:

package pac1

type MyType1 = struct{}

pac2:

package pac2

type MyType2 = struct{}

main:

package main

import (
	"exeexe/pac1"
	"exeexe/pac2"
)

type M1 struct {
	pac1.MyType1
}

type M2 struct {
	pac2.MyType2
}

func main() {
	_ = M2(M1{})
}

(3) This example shows the actual problem. The only difference compared to the previous example is that embedded field (pac2.MyType2) is now replaced by non-embedded (ordinary) field with the name MyType1 (type is the same). Since specification for type identity doesn't make a distinct between embedded and ordinary field in the struct this should be valid and compile (all requirements are met).

pac1:

package pac1

type MyType1 = struct{}

pac2:

package pac2

type MyType2 = struct{}

main:

package main

import (
	"exeexe/pac1"
	"exeexe/pac2"
)

type M1 struct {
	pac1.MyType1
}

type M2 struct {
	MyType1 pac2.MyType2
}

func main() {
	_ = M2(M1{})
}

(4) This example just shows that even when MyType1 pac2.MyType2 is replaced with MyType1 pac1.MyType1 in M2 (so just the name is added), it still doesn't compile.

pac1:

package pac1

type MyType1 = struct{}

pac2:

package pac2

type MyType2 = struct{}

main:

package main

import (
	"exeexe/pac1"
)

type M1 struct {
	pac1.MyType1
}

type M2 struct {
	MyType1 pac1.MyType1
}

func main() {
	_ = M2(M1{})
}

What did you see happen?

Inconsistency between specification and implementation

What did you expect to see?

Since I am following specification, I expect examples (3) and (4) to compile, or to modify the specification to address the difference.

[gabyhelp]

Related Issues and Documentation

• cmd/compile: Embedded field names are not tracked correctly with aliased types #28655 (closed)
• spec: incorrect requirement for the embedded field #69460 (closed)
• Multiple embedded struct fields can cause collisions #24235 (closed)
• spec: type identity section not fully updated for 1.9 #22202 (closed)
• cmd/compile: cannot compile with alias type used in multiple files #50925 (closed)
• spec: Interplay between type conversions and embedded structs is not clear. #53975
• internal compile error caused by function type alias #36419 (closed)
• proposal: spec: treat blank struct fields as having the same names for type identity #21967 (closed)
• cmd/cgo: types regression for anonymous structs #38408 (closed)
• gccgo: internal compiler error for (invalid) program using interface aliases #25302 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[zigo101]

A clever finding.

BTW, it looks your code doesn't prove type identity, but conversion rules. Though I believe that your point is described well and it applies to conversions too.

[zigo101]

The code is used to prove type identity:

package main

type MyType1 = struct{}

type M1 = struct {
	MyType1
}

type M2 = struct {
	MyType1 MyType1
}

func main() {
	indentify := any(M1{}) == any(M2{})
	println(indentify) // false
}

[leabit]

@zigo101 Right, I just used conversion as a quick way to check type identity equality. According to specification if two types are identical, values of these types can be assigned to each other. Further, if they are assignable, conversion is possible.

[leabit]

@griesemer @ianlancetaylor

[cuonglm]

As I understand the spec, in case of (3) and (4), M1 and M2 does not have the same sequence of fields, because MyType1 of M1 is an embedded field, while MyType1 of M2 is not. These fields have the same name but are different fields.

[leabit]

BTW, if I use a @zigo101 way of checking type identity, then even the first example fails (it prints false). However, the conversion is successful (as already stated).

@cuonglm Specification doesn't make a distinction between embedded and ordinary fields. From spec:

Promoted fields act like ordinary fields of a struct except that they cannot be used as field names in composite literals of the struct.

Even if you are right, then the first example with indentify := any(M1{}) == any(M2{}) must print true.

[zigo101]

The problem shown in the first example should be implementation bug in my understanding.

[cuonglm]

Even if you are right, then the first example with indentify := any(M1{}) == any(M2{}) must print true.

I don't get it.

You can't do M1{} == M2{} because they are distincted types, thus any(M1{}) == any(M2{}) should print false IMHO.

[cuonglm]

Specification doesn't make a distinction between embedded and ordinary fields. From spec:

Don't that your quote show the difference? "act like" does not mean they are the same fields, causing M1 and M2 don't have the same sequence of fields

[zigo101]

Aha, @cuonglm is right here. M1 and M2 and not alias declarations. So they are distinct types. No problem is shown in example 1.

[edit] When they are alias declarations, then M1 and M2 does denote the same type: https://go.dev/play/p/nR3-nts_kc7

[leabit]

Then how is conversion possible?

[cuonglm]

Then how is conversion possible?

It's the same manner with converting from a float to a int, following a set of rules, which you can read here: https://go.dev/ref/spec#Conversions

[zigo101]

Because in example 1, M1 and M2 shares the same underlying type.

The point (inaccuracy in spec) mentioned by @leabit can still be demonstrated in this example: #69472 (comment)

[cuonglm]

Because in example 1, M1 and M2 shares the same underlying type.

The point (inaccuracy in spec) mentioned by @leabit can still be demonstrated in this example: #69472 (comment)

As I explained above, M1 and M2 don't have the same sequence of fields. If you laid them out literally, M1 is:

struct{main.MyType1}

while M2 is:

struct{MyType1 main.MyType1}

They don't satisfy the type identity definition in spec:

two types are identical if their underlying type literals are structurally equivalent; that is, they have the same literal structure and corresponding components have identical types