When to use pointers

Direct Answer

Use a pointer when mutation must be visible to the caller, when copying a large struct would be wasteful, or when nil has a deliberate meaning such as 'not supplied'. Value parameters and receivers work on a copy and are ideal for small immutable-style data. Pointer forms share one value and support mutation, but they introduce nil handling and make ownership less local.

Deep Dive & Architecture

For a nil-pointer panic, start at the dereference in the stack trace and move backward to the assignment or function return that produced nil.

Check constructor results, map lookups that return pointer values, optional request fields, interface values that may hold typed nil pointers, and concurrent mutation.

Use a pointer when mutation must be visible to the caller, when copying a large struct would be wasteful, or when nil has a deliberate meaning such as 'not supplied'. Value parameters and receivers work on a copy and are ideal for small immutable-style data. Pointer forms share one value and support mutation, but they introduce nil handling and make ownership less local.

The common mistake is dereferencing a nil pointer or using a pointer when ordinary value semantics would be simpler. A nil pointer has no value behind it, so *p or p.Field can panic. Check optional pointers at boundaries, return useful errors with nil results, use value semantics by default for small data, and choose one receiver style consistently for a type.

Code Example

func increment(n *int) {
    *n++
}

count := 2
increment(&count)
fmt.Println(count) // 3

Common Mistakes & Pitfalls

Saying “it depends” without naming the condition that changes the choice.