Go passes every argument by value — how do you write a function that modifies the caller's struct?

## The one rule Go is a strictly **pass-by-value** language. There is no `ref` parameter, no implicit aliasing, no "objects are references" special case. Every function argument, every return value, every assignment and every channel send copies the value bit for bit. Once you internalise that single sentence, most of the surprises in this area disappear. ```go type Player struct { Name string HP int } func heal(p Player) { p.HP += 10 } ``` Calling `heal(pl)` copies the whole `Player` struct — both fields — into the parameter `p`. The function increments a field of that copy, the copy is discarded when the call returns, and the caller's `pl.HP` is exactly what it was. Nothing is "optimised away"; the compiler may well keep the copy in registers, but the *semantics* are a copy. ## Making the mutation visible: `&x` and `*T` To let the callee reach the caller's variable, hand it the variable's **address**: ```go func heal(p *Player) { p.HP += 10 } pl := Player{Name: "ada", HP: 50} heal(&pl) // pl.HP is now 60 ``` Two operators do the work, and they are mirror images: - `&x` is the **address-of** operator. Applied to a variable of type `T` it yields a value of type `*T` — a pointer that identifies where `x` lives. - `*p` is the **dereference** operator. Applied to a value of type `*T` it yields the `T` stored there. Confusingly, `*` also appears in *types*: `*Player` read in a declaration is "pointer to Player", while `*p` read in an expression is "the Player that p points at". Go removes most of the punctuation you would write in C: for a `p` of type `*Player`, the selector `p.HP` automatically means `(*p).HP`. Both compile; the short form is universal Go. There is no `->` operator in the language. ## The pointer itself is still a value This is the half candidates usually miss. A `*Player` parameter is copied like everything else — what is copied is the *address*, not the struct. Consequences: ```go func reset(p *Player) { *p = Player{} // caller SEES this: writes through the address p = &Player{HP: 1} // caller does NOT see this: rebinds the local copy } ``` Writes *through* the pointer reach the caller's memory. Rebinding the pointer variable only changes the callee's copy of the address. If a function genuinely needs to make the caller's *variable* point somewhere else, it needs a `**Player`, or — far more idiomatic in Go — it should return the new value. ## Dereferencing nothing A pointer's zero value is `nil`. Dereferencing it — `*p`, or `p.HP`, which dereferences implicitly — panics at run time with `invalid memory address or nil pointer dereference`. A function that accepts a `*Player` is implicitly accepting "or nothing", which is one real cost of choosing a pointer parameter: values cannot be absent, pointers can. ## No pointer arithmetic Go deliberately omits `p + 1`, `p++` on pointers, and casts between pointer types. A `*Player` can only be dereferenced, compared for equality, or assigned. That is what allows the garbage collector to know precisely which words are pointers, and it is why bounds-checked slices — not walking pointers — are how Go traverses memory. (The `unsafe` package can break this, at the cost of leaving the safe language.) ## Choosing between a value and a pointer parameter Prefer a **value** when the function only reads, the struct is small, and you want callers to be certain nothing is retained or mutated. Prefer a **pointer** when you must mutate the caller's data, when the struct is large enough that copying it per call is measurable, when the value must not be copied at all (anything containing a `sync.Mutex` must be passed by pointer once it has been used), or when the type's methods already use pointer receivers so mixing would be inconsistent. "Big structs must be pointers" is a benchmarking question, not a rule — a two- or three-word struct is usually cheaper to copy than to chase through memory. Finally, note what this rule does *not* say. It says the *value* is copied, not that the data behind it is. Slices, maps, channels, function values and interface values all contain a pointer inside them, so copying such a value copies a handle to shared data — which is why a function can mutate the caller's map without ever taking its address.