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.

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)?

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.

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

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)
}

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

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

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

Are the following descriptions accurate?

• A type name T can be embedded as an embedded field unless T denotes a pointer type which base type is either a pointer or an interface type.
• A pointer type *T, where T is a type name denoting the base type of the pointer type, can be embedded as an embedded field only if T doesn't denote a pointer or interface type.

@go101 I believe those descriptions are still accurate; by type name we do mean a name denoting a type (and it could be an alias).

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.

The above shown current description excludes the following T alias.

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

Or the following one?

An embedded field must be specified as the form T or *T, where T is a type name and the embedded type may not be a pointer type whose base type is a pointer or interface type.

A question, why pointer types whose base types are pointer and interface types can't be embedded?
If they can, the rule can be much simplified as An embedded field must be specified as a type name or a type literal which can provide an identifier as the field name.

@go101 Originally, we wanted to avoid situations such as **T embeddings, etc. There are also interactions with lookup of embedded fields and methods. You're right that there are certainly unanswered questions here, and possibly inconsistencies. I'd love to simplify this, as it is only going to get more complex if we have generics as well. Thanks for pointing out the inconsistencies. We will get to this eventually; but at the moment it is not a high priority.

I think I got why pointer types whose base types are pointer and interface types can't be embedded.
The reason is, except pointer and interface types, for each type T of other types, the method set of *T is always a super-set of T.

Just found my above description is not accurate. It missed the following highlighted case:

• A type name T can be embedded as an embedded field unless T denotes a defined pointer type or a pointer type which base type is either a pointer or an interface type.
• A pointer type *T, where T is a type name denoting the base type of the pointer type, can be embedded as an embedded field unless type name T denotes a pointer or interface type.

I just noticed that, gc and gccgo have different behaviors on this inaccuracy.
For the following code, gc compiles it okay, but gccgo reports an error.

package main

type P = *bool
type T struct {
	P
}

func main() {}

@go101 At first glance I think that is a gccgo bug. Want to file an issue for that? Thanks.

Just FYI: go/types also accepts this code.