Why does `for _, p := range players` over a []Player silently lose writes to p?

## What `range` actually hands you A two-variable `range` over a slice is defined as: for each index in turn, assign the index to the first variable and **assign the element to the second variable**. That word — assign — is the whole answer, because assignment in Go copies. ```go for _, p := range players { // p is a Player, copied out of players[i] p.HP -= 10 // decrements the copy } ``` After the loop, every `players[i].HP` is untouched. The compiler cannot warn you: assigning to a field of a local variable is legitimate code, and `go vet` does not flag it either. It is one of the most common review findings in Go written by people arriving from languages where a for-each variable aliases the element. ## Why it feels wrong In many languages a collection holds *references* to objects, so the loop variable and the collection entry denote the same object and mutating through either is visible in both. A Go `[]Player` does not hold references — it holds `Player` structs laid out end to end in a backing array. Copying one out is a real copy of every field. The mental correction is: **`[]Player` is a slice of values; `[]*Player` is a slice of references.** ## The two fixes **Index into the slice.** `players[i]` is not a copy — it names the element inside the backing array, so assigning to its field writes to the array: ```go for i := range players { players[i].HP -= 10 } ``` The one-variable form `for i := range players` is also the cheapest loop shape: it never materialises the element copy at all, which matters when the element is a large struct. **Hold pointers.** If the slice is a `[]*Player`, the copied loop value is a pointer, and writing through it reaches the shared struct: ```go for _, p := range players { // players is []*Player p.HP -= 10 } ``` That is not automatically the better design. A `[]*Player` costs an extra indirection per access, spreads the entities across memory instead of packing them contiguously, and — the part that matters for a game-server tick loop — hands every holder of one of those pointers the ability to mutate an entity from anywhere, which is exactly how a concurrent write sneaks in later. A `[]Player` mutated by index keeps ownership in one place. ## What does *not* fix it - **Per-iteration loop variables.** Go 1.22 gave each iteration its own loop variables, which fixed the classic closure-capture bug where every goroutine saw the final value. It changed nothing here: a per-iteration `p` is still a *copy* of the element, not an alias for it. - **Taking the address of the loop variable.** `&p` is the address of the copy. Before per-iteration variables it was also the *same* address every iteration, which produced a slice where every pointer aimed at the last element — a related classic bug. Even now, `&p` points at a copy, so appending it to a `[]*Player` gives you pointers into copies rather than into the slice. Use `&players[i]` when you want a pointer to the element itself. - **Making the field a pointer.** `p.HPPtr` would work, but restructuring the data to work around a loop form is the wrong lever. ## The same rule, everywhere else This is not a `range` quirk; it is Go's uniform value semantics showing up in a loop. The identical copy happens when you write `p := players[0]`, when you pass `players[0]` to a function, and when you send it on a channel. `range` just makes it easy to miss because the copy is implicit in the loop header. One more variant worth knowing: ranging over an **array** (not a slice) evaluates the range expression once and iterates over a copy of the whole array, so even the index form `arr[i] = ...` inside `for _, v := range arr` is reading from a snapshot. Ranging over a **map** yields copies of both key and value, and map elements are not addressable at all, so `m[k].Field = v` does not even compile for a struct-valued map — you must read the value out, modify it, and store it back. ## How to catch it in review The smell is a two-variable `range` whose body **writes** to the second variable. Reading it is fine and idiomatic; writing to it is almost always a bug or a pointless assignment. If a reviewer sees `for _, x := range xs` followed by `x.Something = ...`, that is the finding — ask whether the author meant `xs[i]`.