about struct's anonymous field

[6355...@qq.com]

"The Go Programming Language Specification" says "A field declared
with a type but no explicit field name is an anonymous field
(colloquially called an embedded field). Such a field type 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".

I want to know why a pointer to a interface can not be a struct's
anonymous field?

Thank you very much!

[Kyle Lemons]

I don't know this for sure, but I suspect it has to do with wanting to be able to know the address of the function being called or knowing the itab that will be used to determine the method call.  Adding in extra levels of indirection makes this harder on code generation and might have "hidden" performance issues.

Chance are, however, that a pointer to an interface type is *not* what you want.  A pointer to an interface holding a value is not the same as an interface holding a pointer to that value.

~K 

[Steven Blenkinsop]

On Monday, November 14, 2011, Kyle Lemons <kev...@google.com> wrote:
> I don't know this for sure, but I suspect it has to do with wanting to be able to know the address of the function being called or knowing the itab that will be used to determine the method call.  Adding in extra levels of indirection makes this harder on code generation and might have "hidden" performance issues.

IIRC, calling methods on pointers to interfaces used to be permitted, but got removed when it became apparent that people were using them incorrectly, a lot. And, if you can't call methods on them, it doesn't make sense to embed them. If you *really* need it, you can embed the interface in a struct, then embed a pointer to that struct. I can't see this being all that useful, though, and if you think it is, chances are you're doing something wrong.

[6355...@qq.com]

this is my test code:
--------------------------------------
type MyIface interface {
Abs()
}

type pInt *int
type MyStruct struct {
*pInt
*MyIface
}
-------------------------------------
compile it and we will see:
prog.go:11: embedded type cannot be a pointer
prog.go:12: embedded type cannot be a pointer to interface

I want to know the underlying reason why the language doesn't allow
pointer to pointer and pointer to interface as a anonymous field of
struct

[Steven Blenkinsop]

On Mon, Nov 14, 2011 at 8:23 PM, 6355...@qq.com <6355...@qq.com> wrote:

I want to know the underline reason why the language doesn't allow

pointer to pointer and pointer to interface as a anonymous field of
struct

The reason why you can't have pointer to pointer and pointer to interface anonymous fields is that these types don't have methods. The whole point of anonymous fields is that methods get promoted. I already explained why interfaces don't have methods: a lot of people were using pointers to interfaces incorrectly and unnecessarily, and there weren't any known valid uses, so the language was changed to actively discourage this usage by making pointers to interfaces have no methods.

As for pointers to pointers, they don't have methods because there isn't really a reason to implement it, and there's some uneasiness about what methods you can call where. Such as, by dereferencing  a `type P *T`, you might suddenly be able to call *T methods and not P methods on it. While arguably its possible to sort this out, the seeming uselessness and confusion were enough for the language authors to disallow it.

You can get around both of these restrictions by having the pointer or interface be an anonymous field of a struct, and then have a pointer to that struct be an anonymous field.

[6355...@qq.com]

got it! Thank you very much!

On 11月15日, 上午9时42分, Steven Blenkinsop <steven...@gmail.com> wrote:

>
> The reason why you can't have pointer to pointer and pointer to interface
> anonymous fields is that these types don't have methods. The whole point of
> anonymous fields is that methods get promoted. I already explained why
> interfaces don't have methods: a lot of people were using pointers to

> interfaces incorrectly and unnecessarily, and there weren't any known *valid
> * uses, so the language was changed to actively discourage this usage by