spec: Embedded fields don't need to be defined types

[Merovius]

The spec says:

Given a struct type S and a defined type T, promoted methods are included in the method set of the struct as follows:

If S contains an embedded field T, the method sets of S and *S both include promoted methods with receiver T. The method set of *S also includes promoted methods with receiver *T.
If S contains an embedded field *T, the method sets of S and *S both include promoted methods with receiver T or *T.

The emphasis is mine. It's a bit contrived, but with the introduction of aliases, I don't think the embedded field has to be a defined type anymore:

type A struct{}

func (A) Foo() {
}

type B = struct {
	A
}

type C struct {
	B
}

In this example, B is not a defined type, but C still gets a Foo method promoted from it. The wording should probably be "type name" instead of "defined type"?

[andybons]

@griesemer @ianlancetaylor

[griesemer]

Probably. Thanks for reporting.

Somewhat related, the term "defined type" is really unfortunate (and yes, I am guilty as charged). In retrospect it would have been better to call them "nominal types".

[robpike]

Bodacious types.

[gopherbot]

Change https://go.dev/cl/406054 mentions this issue: spec: fix prose about promoted methods of embedded fields