## Why is Copying Instances of Go Types with Pointer Receiver Methods Dangerous?

Pitfalls of Copying Instances with Pointer Receiver Methods

In Go, if all methods for a named type T have a receiver type of T itself (not *T), copying instances of that type is considered safe. This is because any method call necessarily operates on a copy, ensuring that the original value remains unmodified. However, if any method for T has a pointer receiver, copying instances of T can be dangerous.

Explanation

When calling a method, the value the method is invoked on is first copied, and the copy is passed as the receiver. If a type only has methods with value receivers, it guarantees that the methods cannot modify the original value, regardless of their actions. This is because a copy is always utilized, shielding the original from unintentional alterations.

However, if a type has methods with pointer receivers, those methods can modify the original pointed value rather than its copy. This is because the method receives a pointer to the original value, allowing it to alter the underlying data.

Example

Consider a wrapper type Wrapper:

type Wrapper struct {
    v int
    p *int
}

With a Set() method to ensure both fields contain the same value:

func (w *Wrapper) Set(v int) {
    w.v = v
    *w.p = v
}

If we create an instance of Wrapper:

a := Wrapper{v: 0, p: new(int)}

And subsequently make a copy (b) of a:

b := a

After setting a to 1 using Set():

a.Set(1)

We would expect both a and b to have their fields set to 1. However, printing their values reveals a different story:

fmt.Printf("a.v=%d, a.p=%d;  b.v=%d, b.p=%d\n", a.v, *a.p, b.v, *b.p)

Output:

a.v=1, a.p=1;  b.v=0, b.p=1

The reason for this discrepancy is that while the pointer in b is copied, it still references the same underlying data as the pointer in a. When Set() modifies the pointed value, it affects both copies of Wrapper. However, the non-pointer field v remains distinct between a and b.

Best Practice

To avoid this issue, it's recommended to refrain from copying instances of types with pointer receiver methods. If working with pointer values is necessary, copying the pointer itself (*T) is a viable alternative.

The above is the detailed content of ## Why is Copying Instances of Go Types with Pointer Receiver Methods Dangerous?. For more information, please follow other related articles on the PHP Chinese website!