A method that must update its receiver needs a pointer receiver. With `func (c customer) add(v float64)`, Go copies the customer: adding 50 to a balance of 100 leaves the original at 100. With `func (c *customer) add(v float64)`, Go copies the pointer instead, so the original balance becomes 150. This is not pass-by-reference; the copied pointer identifies the same object. section 6.1
type customer struct {
balance float64
}
func (c *customer) add(operation float64) { #1
c.balance += operation
}
func main() {
c := customer{balance: 100.0}
c.add(50.0)
fmt.Printf("balance: %.2f\n", c.balance) #2
}
The pointer-receiver version of `add` updates the original customer and prints `150.00`. section 6.1
Choose a receiver for the behavior and type, not by reflex:
- Use a pointer when the method must change the receiver, including when a slice method must append to the receiver itself. Use one when the receiver contains a field that cannot be copied, such as a sync type. section 6.1
- Consider a pointer for a large object to avoid copying it; benchmark when size makes the choice uncertain. A value receiver can still change an object reached through one of its pointer fields, even though the receiver itself was copied. section 6.1
A pointer receiver may be nil. A method can be called on a nil pointer if its implementation does not need to dereference it. But returning a nil `*MultiError` as an `error` does not return a nil interface: an `err != nil` check succeeds even though formatting the error prints `<nil>`. Return the pointer only when it is non-nil; otherwise return an explicit `nil`. section 6.4
A deferred call sees a later change
Given `s := &Struct{id: "foo"}`, `defer s.print()` followed by `s.id = "bar"` prints `bar` when `print` has a pointer receiver. The receiver is evaluated when `defer` runs, but the copied pointer still identifies the struct that changes. With a value receiver, the deferred call prints `foo` because it holds the earlier copy. section 6.6.2
