In Go, what changes when a struct embeds a pointer type or an interface instead of a struct value?

## The selector rules do not change An embedded field may be a type name `T`, a pointer `*T` to a non-interface type, or an interface type. In every case the implicit field name is the unqualified type name — `*Grid` gives a field named `Grid`, `io.Reader` gives a field named `Reader` — and promotion works exactly as it does for an embedded struct value. `d.Rows` on a struct embedding `*Grid` compiles to a pointer dereference plus a field access, just as `d.Grid.Rows` would. What differs is what the zero value means, and what you are saying about the relationship. ## Embedding a pointer: the zero value is a trap ```go type Grid struct{ Rows int } func (g *Grid) Resize(rows int) { g.Rows = rows } type Dashboard struct { *Grid Title string } var d Dashboard d.Resize(24) // panics: the embedded *Grid is nil ``` With an embedded `Grid` value, `var d Dashboard` is immediately usable — the inner struct is zeroed in place. With `*Grid` the field is nil, so the first promoted access dereferences nil and panics at run time. Nothing at compile time warns you, which makes this a genuine production bug rather than a curiosity: a struct that used to embed a value and was changed to embed a pointer keeps compiling and starts panicking on whatever path forgot to construct it. Why do it anyway? Three honest reasons: - **Sharing.** Several outer values can embed the same `*Grid` and see each other's mutations. - **Optionality.** A nil embedded pointer is a meaningful absent, if every promoted use is guarded. - **Size and copying.** The outer struct carries one word instead of the whole embedded struct. A related detail: an embedded `*T` promotes the methods declared with receiver `T` and with receiver `*T` alike, so `Resize` above is reachable even from a non-addressable `Dashboard`, whereas an embedded value would only reach a pointer-receiver method through an addressable outer value. ## Embedding an interface: implementation for free ```go type countingReader struct { io.Reader // promotes Read; the type satisfies io.Reader immediately n int64 } func (c *countingReader) Read(p []byte) (int, error) { n, err := c.Reader.Read(p) c.n += int64(n) return n, err } ``` The embedded interface field contributes its whole method set to the outer type, so `countingReader` satisfies `io.Reader` before you write a line. You then declare only the methods you want to handle yourself; at depth zero they shadow the promoted ones, and inside them you reach the wrapped value through the field's implicit name, `c.Reader`. This is the standard decorator shape in Go, and it scales to wide interfaces: to intercept one method of a twelve-method interface you declare one method instead of twelve forwarders. The cost is that the compiler no longer protects you. The eleven methods you did not write are promoted from a field that may be nil, and if it is, calling one panics on a nil interface. The type checker cannot tell the difference between `countingReader{Reader: f}` and `countingReader{}`. A second, deliberate use of the same trick is a partial test double: embed the interface, leave it nil, implement only the methods the test exercises, and let any unexpected call panic loudly rather than silently returning a zero value. ## What you may not embed An embedded field must be written as a type name `T` or as `*T` where `T` is a non-interface type name, and `T` itself may not be a pointer type. So: - `io.Reader` — legal, embeds the interface. - `*Grid` — legal. - `*io.Reader` — illegal; you cannot embed a pointer to an interface. There is almost never a reason to want one either, since an interface value is already a reference-like two-word value. - A defined type whose underlying type is a pointer — illegal as an embedded field. ## Choosing between the three Embed a **value** when the inner data is genuinely part of the outer thing and the zero value should work. Embed a **pointer** when the inner thing is shared, optional, or large, and accept that construction becomes mandatory. Embed an **interface** when you are wrapping something you do not own and want to intercept a subset of its behaviour — and when you do, treat the constructor as the only supported way to build the type, because the zero value of that type is a panic waiting for a caller.