10 — Pointers

// new(T) — allocates a zero-valued T, returns *T. Rarely used.
p := new(int)   // *int, *p = 0
*p = 5

// &T{} — idiomatic for structs (can initialize fields):
u := &User{Name: "Alice"}  // *User, fields initialized

// `&T{}` is almost always clearer than `new(T)` — you can set fields
// in the same expression. Use new only when you need a *T for a
// non-struct type and don't want a named variable:
//   p := new(int)  vs  var x int; p := &x  — new is slightly cleaner here.

💡 Tips & Tricks

• Performance: run go build -gcflags='-m' ./... to see escape analysis — it tells you which variables escape to the heap. In hot paths, eliminating escapes (keeping values on the stack) is the #1 allocation-reduction technique.
• Idiom: use pointer receivers consistently — if ANY method has a pointer receiver, make ALL methods pointer receivers. Mixing value and pointer receivers causes method-set confusion and is flagged by linters.
• Performance: don't return *T to "avoid a copy" for small structs — escape analysis may heap-allocate the pointer, adding GC pressure worse than a value copy. For structs ≤ 64 bytes, value returns are often faster (no allocation, no GC).
• Idiom: use *T (pointer to a value type) for optional fields where "not set" (nil) differs from "set to zero" — *time.Duration where nil = default, 0 = no timeout. This is the "nullability" pattern for value types.
• Safety: nil pointer dereference is a runtime panic, not a compile error. Always check if p != nil before dereferencing nullable pointers. For exported APIs, document nil behavior ("returns nil if not found").
• Debug: go build -gcflags='-m -m' shows WHY a variable escapes — "p does not escape because ..." or "leaking param: p". This helps understand which code patterns cause heap allocations.

⚠️ Edge Cases & Gotchas

• No pointer arithmetic: p++ (to move to the next element) is illegal (except unsafe.Pointer). Go pointers are references, not computable addresses.
• nil pointer dereference panics at runtime: *p where p == nil is a runtime panic (not a compile error). Check before dereferencing.
• Returning &local is safe: escape analysis moves the local to the heap if its address escapes. The GC manages its lifetime. No dangling pointers in Go.
• &T{} vs new(T): &User{Name: "Alice"} is idiomatic (initializes fields); new(User) returns a zero-value *User (no initialization). Prefer &T{}.
• Pointer to map/slice/chan is usually wrong: these are already reference types (internally pointers). *map[K]V is a pointer to a map pointer — double indirection. Pass the map directly.
• Copy of a struct with pointer/slice fields is shallow: a := S{Items: []int{1,2}}; b := a — b.Items shares the same underlying array. b.Items[0] = 99 affects a.Items[0]. Use slices.Clone or copy for deep copies.
• *p++ is (*p)++: Go parses *p++ as dereference-then-increment the value. No C-style ambiguity.
• Passing a large struct by value copies it: func f(u User) copies the whole User on every call. For large structs, use func f(u *User). For small structs (≤ 64 bytes), the value copy is cheaper than the pointer indirection.
• Pointers to loop variables (pre-1.22): for _, v := range items { save(&v) } — pre-1.22, all &v point to the same v (final value). 1.22+ fixes this. Portable fix: v := v; save(&v).
• Interface boxing causes escape: var i any = x moves x to the heap (the interface needs a pointer to the value). In hot paths, avoid passing values through any — use concrete types.
• unsafe.Pointer bypasses all safety: unsafe.Pointer can convert between pointer types, do arithmetic, and read/write arbitrary memory. Only for CGO, low-level optimization, or reflect. Misuse causes crashes, data corruption, and security holes.

🧠 Quick Quiz

func f() *int {
    x := 42
    return &x
}

func g() int {
    x := 42
    return x
}