Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Merovius opened this issue Sep 28, 2020 · 4 comments
Closed

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

Merovius opened this issue Sep 28, 2020 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@Merovius
Copy link
Contributor

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
Copy link
Member

@griesemer @ianlancetaylor

@andybons andybons added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 29, 2020
@andybons andybons added this to the Unplanned milestone Sep 29, 2020
@griesemer
Copy link
Contributor

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".

@griesemer griesemer self-assigned this Sep 29, 2020
@robpike
Copy link
Contributor

robpike commented Sep 29, 2020

Bodacious types.

@griesemer griesemer modified the milestones: Unplanned, Go1.19 May 12, 2022
@gopherbot
Copy link

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

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants