When to Embed a Pointer to a Struct vs. the Struct Itself in Go?

Embedding a Pointer to a Struct vs. Embedding the Struct Itself

In the given scenario, where a struct type A is used as a pointer and solely contains pointer receivers, there exists a distinction between embedding a struct type B as B versus *B.

Zero Value Behavior

The most apparent difference lies in the zero values of the resultant structures. When embedding B as is, the zero value of type A will include an embedded object of type B, which also holds its zero value. This enables seamless usage of the embedded field without prior initialization:

type B struct {
    X int
}

func (b *B) Print() { fmt.Printf("%d\n", b.X) }

type AObj struct {
    B
}

var aObj AObj
aObj.Print() // prints 0

On the other hand, embedding *B results in a zero value with a nil pointer, preventing direct field access:

type APtr struct {
    *B
}

var aPtr APtr
aPtr.Print() // panics

Field Copying

When creating new objects of type A, the behavior of field copying aligns with intuition. Embedding B directly creates a copy of the embedded object within the new object, preserving independence:

aObj2 := aObj
aObj.X = 1
aObj2.Print() // prints 0, due to a separate instance of B

Conversely, embedding *B creates a copy of the pointer rather than the underlying concrete object. This means that both objects share the same B instance, impacting field modifications:

aPtr.B = &B{}
aPtr2 := aPtr
aPtr.X = 1
aPtr2.Print() // prints 1, as both objects point to the same B

In essence, embedding B creates distinct instances of the contained struct, while embedding *B shares a single concrete instance across multiple embedded structures. This distinction affects both the zero value semantics and the behavior of field copying.

The above is the detailed content of When to Embed a Pointer to a Struct vs. the Struct Itself in Go?. For more information, please follow other related articles on the PHP Chinese website!