Why can a write expressed as one combined address not be lost, when the same write split in two can be?
answer
- evaluate the address, then store
- who actually performs the write
- no intermediate to absorb it
- one statement, full address
- the diagnostic is a heuristic
basics
~20 sOne combined address hands the whole target, rows and column together, to the original table, which performs the write itself. Split in two, the second step stores into an intermediate the first step produced, and that intermediate may be discarded.
solid answer
~40 sIn the split form the language evaluates the address, produces a result object, and only then performs the store — so the store's target is that object and the original is never asked to do anything. In the combined form the full address is an argument to the original's own write: the object that owns the data is the one doing the writing, and there is no intermediate that can absorb the value. That is a correctness difference, not a style preference. Whether anything tells you when the split form went wrong varies by design: some emit a heuristic diagnostic that both misses cases and false-alarms, some define the behaviour so the split write reliably never reaches the original and emit nothing, and immutable-by-default designs simply return a new object you then drop.
code
pseudocode · 10 lines# TWO STATEMENTS - the store targets whatever the first one produced
chosen <- rows_where(table, region equals "west")
write_column(chosen, "discount", 0.10) # the value lands in `chosen`
# `table` is not mentioned above; only a read of `table` can tell you what happened
# ONE STATEMENT - the table itself performs the addressed write
write_cells(table, rows: region equals "west", column: "discount", value: 0.10)
# either way, prove it against the original
check read_cells(table, rows: region equals "west", column: "discount") all equal 0.10go deeper
Remember the rule of thumb: put the whole target — which rows and which column — into one statement, so the table itself is the thing being written to.
Explain the evaluation order. The address is evaluated to an object first, and the store then targets that object; the combined form removes the object, so it removes the failure.
Show that you do not rely on the diagnostic. Name why it is a heuristic, describe the partial-update signature that appears when forms are mixed, and add the read-back where the result is consumed downstream.
Argue the review rule from the class of defect it eliminates, and account for designs with no combined surface, where the rule has to be stated as build-and-assign-back instead.
## Evaluate, then store An assignment through an address is not one indivisible act. The host evaluates the address expression first, producing some object, and then performs the store against whatever that evaluation produced. Everything about this failure follows from that ordering. When the address is written in two steps — address the table, then address the result of that — the intermediate object is the store's target. The original's name is not part of the second step, so the original has no opportunity to participate. If the intermediate happens to be **a window onto the same bytes** (a result that reads and writes the original's storage) the value arrives in the original as a side effect. If it is **storage of its own** (freshly allocated bytes) the value arrives nowhere that anyone will ever read. ## What the combined address changes When the full address is given in one statement, the whole target — which rows, which column — is handed to the original object as part of a single write. The object that owns the data performs the write on itself. There is no second object in the picture, so there is nothing for the value to land in by mistake. | | what the store targets | can the value be lost? | what warns you | |---|---|---|---| | two addressing steps | the intermediate the first step produced | yes, silently | a heuristic diagnostic at best, often nothing | | one combined address | the original, which writes itself | no | not applicable | Note what the table does **not** say: it does not say the split form always fails. It fails when the intermediate owned its bytes, and it succeeds by luck when the intermediate was a window. That conditional success is the trap — the same code reviewed, tested and shipped can behave differently on a different selection shape, a different column set, or a different tool. ## What the diagnostic is worth - It is a **heuristic**: the design cannot always tell, at the moment of the store, whether the intermediate owned its storage, so it guesses from the shape of the expression. - It **misses** real losses, notably where the two steps are separated by other code or hidden behind a helper. - It **fires on safe writes**, which trains people to silence it. - Several designs emit **nothing at all** — some because the behaviour is defined rather than anomalous, some because a discarded result is not, in their model, an error. So the diagnostic is evidence you may act on, never a guarantee you may rely on. ## When there is no combined write surface Not every design offers one, and some offer no in-place write at all. The portable form then is to build the new state and assign it back in a single statement: 1. compute the replacement values for the whole column, leaving untouched rows carrying their existing value; 2. assign that column back onto the table in one statement, so the table is the object being modified; 3. read back the affected rows from the table and compare them with what you intended. This costs a full-length column of values. Whether that matters depends on the evaluation model: under an eager design each surviving intermediate is a second full allocation, while a design that shares untouched buffers or defers the duplicate until a write pays per modified column rather than per step. Say which model you are in before you argue about the cost. ## The two signatures in production - **Nothing changed.** The most common outcome: the intermediate owned its bytes, absorbed every value, and vanished. Downstream reads see the original data and the numbers look plausible. - **Some of it changed.** Where a routine mixes forms — one write combined, the next split — part of the update lands and part does not, which produces internally inconsistent rows and is much harder to attribute to a single line. Neither signature involves an exception, missing rows, or a change in the size of anything, which is why the review rule is worth more than the debugging skill: **prefer the form that cannot express the bug.**
- Does the order of the two addressing steps matter — rows first, or the column first?Both orders produce an intermediate, so both can lose the write; neither order is a fix. What differs is only which intermediate appears — a set of rows, or a single column — and therefore how likely a given design is to have handed that particular shape back as a window onto the original. Treat both as the same hazard and combine the address.
- If the design offers no combined write, what is the portable substitute?Compute the replacement values for the whole column, with untouched rows keeping their existing value, and assign that column back onto the table in one statement. The table is then the object being modified, so there is no intermediate to lose. Follow it with a read-back of the affected rows.
- Why is this framed as correctness rather than as good style?Because the two forms differ in outcome, not only in appearance. The split form's result depends on whether the intermediate owned its storage, which is a property of the selection shape and of the design rather than of your intent. The combined form has one outcome for all inputs.
saying these in an interview costs you the question
- Calls the one-statement form a style preference rather than a correctness fix.
- Believes a warning always appears when a split write is lost.
- Thinks the combined address is about readability or speed.
- Assumes every design offers a combined write surface.
- Says the split form fails loudly, so it cannot reach production.
- Claims the split form is safe as long as the two steps are adjacent.