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: some wording need to be adjusted for embedding alias of pointer types #22005

Open
go101 opened this Issue Sep 24, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@go101

go101 commented Sep 24, 2017

Now, the wording is

An embedded field must be specified as a type name T or as a pointer to a non-interface type name *T, and T itself may not be a pointer type.

However aliases of *T can also be embedded.

@go101

This comment has been minimized.

Show comment
Hide comment
@go101

go101 Sep 24, 2017

btw, some wording for the receiver type requirements in the Method declarations may also need to be adjusted, as aliases of *T can also be used as receiver types.

go101 commented Sep 24, 2017

btw, some wording for the receiver type requirements in the Method declarations may also need to be adjusted, as aliases of *T can also be used as receiver types.

@griesemer griesemer self-assigned this Sep 24, 2017

@griesemer

This comment has been minimized.

Show comment
Hide comment
@griesemer

griesemer Sep 24, 2017

Contributor

I think those are still correct. We still have named types (any type that has a name); it's just that it may be a defined or an alias type.

The rules for embedding allow alias types.

The rules for method receivers explicitly say that the receiver type must be defined in the same package.

Is there anything specific that you believe needs to be fixed (and why)?

Contributor

griesemer commented Sep 24, 2017

I think those are still correct. We still have named types (any type that has a name); it's just that it may be a defined or an alias type.

The rules for embedding allow alias types.

The rules for method receivers explicitly say that the receiver type must be defined in the same package.

Is there anything specific that you believe needs to be fixed (and why)?

@go101

This comment has been minimized.

Show comment
Hide comment
@go101

go101 Sep 25, 2017

Maybe my English understanding is not correct, for embeddable types, spec says

..., and T itself may not be a pointer type.

However, T can be a pointer type (as an alias)

type T = *int
type S struct{
	T // T is a pointer
}

And for method receivers, the receiver type must be defined in the same package..
However, aliases (which are not defined) declared in the same package can also be used as receiver types.

type S struct{}
type T = S
type P = *S
func (T) f() {}
func (*T) g() {}
func (P) h() {}

Maybe, mention that declared methods on an alias of a type has the same effect as declaring methods on the type itself would be better.

go101 commented Sep 25, 2017

Maybe my English understanding is not correct, for embeddable types, spec says

..., and T itself may not be a pointer type.

However, T can be a pointer type (as an alias)

type T = *int
type S struct{
	T // T is a pointer
}

And for method receivers, the receiver type must be defined in the same package..
However, aliases (which are not defined) declared in the same package can also be used as receiver types.

type S struct{}
type T = S
type P = *S
func (T) f() {}
func (*T) g() {}
func (P) h() {}

Maybe, mention that declared methods on an alias of a type has the same effect as declaring methods on the type itself would be better.

@griesemer

This comment has been minimized.

Show comment
Hide comment
@griesemer

griesemer Sep 25, 2017

Contributor

Hm, you have a point. I'll look into this. Thank you!

Contributor

griesemer commented Sep 25, 2017

Hm, you have a point. I'll look into this. Thank you!

@griesemer griesemer added this to the Go1.10 milestone Sep 25, 2017

@myitcv

This comment has been minimized.

Show comment
Hide comment
@myitcv

myitcv Sep 26, 2017

Member

However, aliases (which are not defined) declared in the same package can also be used as receiver types.

...

Maybe, mention that declared methods on an alias of a type has the same effect as declaring methods on the type itself would be better.

I think this is implicit in the definition of an alias itself; i.e. that an alias is just that, an alias for a defined type (recursive definition), not a type in and of itself.

So in your method examples the receiver types are:

type S struct{}
type T = S
type P = *S
func (T) f() {}   // S
func (*T) g() {}  // *S
func (P) h() {}   // *S

it's just that we're using aliases to refer to those two types.

Similarly with embedding:

type T1 = *int
type S struct{
	T1 // *int; T = int in spec terms (i.e. the "may not be a pointer type" bit)
}
Member

myitcv commented Sep 26, 2017

However, aliases (which are not defined) declared in the same package can also be used as receiver types.

...

Maybe, mention that declared methods on an alias of a type has the same effect as declaring methods on the type itself would be better.

I think this is implicit in the definition of an alias itself; i.e. that an alias is just that, an alias for a defined type (recursive definition), not a type in and of itself.

So in your method examples the receiver types are:

type S struct{}
type T = S
type P = *S
func (T) f() {}   // S
func (*T) g() {}  // *S
func (P) h() {}   // *S

it's just that we're using aliases to refer to those two types.

Similarly with embedding:

type T1 = *int
type S struct{
	T1 // *int; T = int in spec terms (i.e. the "may not be a pointer type" bit)
}

@golang golang deleted a comment Sep 26, 2017

@go101

This comment has been minimized.

Show comment
Hide comment
@go101

go101 Sep 26, 2017

@myitcv yes, no problems on the mechanism here. It is just that some terminologies and some wording need to be clarified. For example, what is a named type? Can an alias be called a type? Is alias of a defined type can also be called defined type? etc.

go101 commented Sep 26, 2017

@myitcv yes, no problems on the mechanism here. It is just that some terminologies and some wording need to be clarified. For example, what is a named type? Can an alias be called a type? Is alias of a defined type can also be called defined type? etc.

@rsc rsc modified the milestones: Go1.10, Go1.11 Dec 14, 2017

@go101

This comment has been minimized.

Show comment
Hide comment
@go101

go101 May 10, 2018

I feel some wording for the method documentations of the refect.Type type also need adjusted.

For example, the word "unnamed" may be better to change to "non-defined".

go101 commented May 10, 2018

I feel some wording for the method documentations of the refect.Type type also need adjusted.

For example, the word "unnamed" may be better to change to "non-defined".

@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot May 10, 2018

Change https://golang.org/cl/112717 mentions this issue: reflect: use 'defined' rather than 'named', use 'embedded' rather than 'anonymous'

gopherbot commented May 10, 2018

Change https://golang.org/cl/112717 mentions this issue: reflect: use 'defined' rather than 'named', use 'embedded' rather than 'anonymous'

gopherbot pushed a commit that referenced this issue May 10, 2018

reflect: use 'defined' rather than 'named', use 'embedded' rather tha…
…n 'anonymous'

On the API level this is just an update of the documentation to match
the current spec more closely.

On the implementation side, this is a rename of various unexported names.

For #22005.

Change-Id: Ie5ae32f3b10f003805240efcceab3d0fd373cd51
Reviewed-on: https://go-review.googlesource.com/112717
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Unplanned Jun 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment