Two names in a tick loop refer to the same entity record; what surprises a reader when one of them is written?

## Two names, one location In the imperative model a variable names a **location**. Assigning a record to a second variable does not duplicate the record; it makes a second name for the same location. From that moment the two names are **aliases**, and every read through either sees the writes made through the other. Nothing announces this. The two names may sit in different functions, in different containers, or one may be an element of a grid and the other a handle cached out of it thirty lines earlier. The mechanism is unremarkable — it is how the paradigm avoids copying large structures — and the cost is entirely in comprehension. A statement's **footprint** is the set of locations it changes. Aliasing means the footprint is not determined by the statement's text. It is determined by the aliasing graph at the moment the statement runs. ## Where aliases come from They rarely arrive by anything as visible as a pointer. Ordinary code makes them constantly: - **assigning a record** to a second variable, which copies the reference and not the fields; - **passing a record to a subroutine**, which gives the callee a name reaching the caller's state; - **placing one record in two containers**, so both containers observe every edit; - **caching a lookup** — holding a handle from a grid cell while other code keeps using the grid; - **a shallow copy of a container**, which duplicates the container's slots while leaving the records inside shared; - **returning an internal record** from a lookup, which hands a caller a live name into your state. Each of these is idiomatic, and each quietly widens some statement's footprint somewhere else. ## Value semantics against reference semantics The same assignment means different things depending on what the name holds. | | The name holds a value | The name holds a reference | |---|---|---| | `b = a` | `b` gets an independent copy | `b` becomes a second name for one record | | writing through `a` | `b` is unaffected | `b` observes the write | | cost of the assignment | grows with the size of the data | constant | | reading a statement | footprint is its text | footprint needs the aliasing graph | Most working languages mix the two — small scalars behaving one way and structured records the other — which is exactly why the surprise is so common. The line `b = a` is written identically in both cases. ## The failure it produces in a tick loop A loop resolves a hit. It reads the attacker's target out of the grid into `target`, and elsewhere in the same tick reads the same grid cell into `neighbour` to compute a proximity bonus. The damage line writes `target.hp`. The bonus computation then reads `neighbour.hp` — and reads the *post-damage* value, because there was only ever one record. The bonus is wrong. No statement mentions both names; no statement is individually incorrect; every read and every write is legal. The defect lives in the relationship between two statements that the text does not show. The same shape produces the classic "my copy changed": a snapshot taken for comparison at the end of the tick was a shallow copy, so the elements inside it are the very records the tick then edits, and the comparison reports that nothing changed. ## What actually removes the question There are only three honest answers, and they are not equally available: 1. **Copy the value at the boundary.** Take a real copy, deep enough that no shared record survives, at the point where state crosses from one owner to another. Correct, and it costs proportional to the data on every crossing. 2. **Make the record immutable.** If the value cannot change, sharing one copy between ten names is unobservable, and the whole aliasing question stops mattering — which is why value-oriented styles do not have this failure mode at all. 3. **Give the location one writer.** Aliases that only read are harmless. Discipline about who may write, stated and enforced somewhere, keeps the footprint knowable even when the graph is wide. Notice what is *not* on the list: reading more carefully. Aliasing defeats local review by construction, so the fix is a property of the data, not an effort of attention. ## What an interviewer is checking They want to hear that you know a name is not a value. The junior answer is "they point at the same thing". The answer that lands says *why that is expensive*: it moves the effect of a statement outside the statement, which is the single largest reason imperative code resists local reasoning — and it is the same property that makes a second worker over one grid so dangerous, since the aliasing graph is what decides whose writes collide.