Why do reviewers reject the temp-free XOR swap of two array slots?

## What the sequence does when the slots are distinct Call the two stored values `A` and `B`, held in distinct slots `a[i]` and `a[j]`. 1. `a[i] = a[i] xor a[j]` leaves `A xor B` in the first slot. 2. `a[j] = a[i] xor a[j]` computes `(A xor B) xor B`, which is `A` by self-inverse and identity, and stores it in the second slot. 3. `a[i] = a[i] xor a[j]` computes `(A xor B) xor A`, which is `B`, and stores it in the first slot. The exchange is real, and it uses no third storage location. That is the whole appeal, and it is why the trick keeps reappearing in code review. ## The aliasing failure Everything above assumed the two slots are different pieces of storage. Suppose they are the same — `i == j`, or two references that happen to point at the same element. Then step 1 is `a[i] = a[i] xor a[i]`, which is zero by self-inverse. The value is destroyed immediately, and steps 2 and 3 have nothing left to reconstruct it from: they compute `0 xor 0` twice. The slot ends holding zero. This is not a contrived case. Any partition or selection routine that walks two indices towards each other will, sooner or later, call its swap with both indices equal — that is what happens when the element under consideration is already where it belongs. A swap through a temporary handles that call as a harmless no-op. The temp-free version turns it into silent data loss, and the corruption surfaces far from its cause: a value quietly becomes zero, the surrounding algorithm keeps running, and the wrong output shows up in some downstream aggregate. If the same value happens never to be equal-indexed in your tests, the bug ships. The general lesson generalises past this one trick: any "clever" in-place update that reads and writes overlapping storage must state explicitly whether its operands may alias, and be guarded or documented accordingly. ## Why it is not faster either The usual justification is that the temp-free version saves a register or a store. Both halves of that claim are weak on any modern general-purpose processor: - **The dependency chain.** The three XOR steps are strictly serial: step 2 needs step 1's result, step 3 needs step 2's. A swap through a temporary is three data movements with no such chain, so a wide out-of-order core can issue them in parallel. Latency, not instruction count, is what you are paying here, and the trick makes latency worse. - **The compiler is already ahead of you.** Optimising compilers routinely implement a temporary swap by renaming which register holds which value, emitting no movement at all. You cannot beat zero instructions with three. - **The register is not scarce.** The scarcity argument belongs to hand-written code for very small processors with a handful of registers and no compiler worth the name. In that setting the trick is a legitimate tool — which is exactly why it exists — but it is not the setting most reviewers are working in. There is a further constraint worth naming: the trick applies only to values on which XOR is defined bit-for-bit. Anything with a representation that is not a plain bit pattern, or where distinct bit patterns must compare equal, is not a candidate at all. ## What to say in review The reviewable statement is not "never use XOR swap", it is "this buys nothing here and introduces an aliasing precondition nobody will remember". If the code needs a swap, use a temporary; if profiling ever shows that the swap itself is the bottleneck — which it essentially never is, because the surrounding memory traffic dominates — the fix is to move less data, not to move it more cleverly. ## The one thing the trick genuinely teaches It is a good interview question precisely because it is a small, complete test of whether the candidate reasons about preconditions instead of pattern-matching on cleverness. The candidate who says "it swaps without a temporary" has read it somewhere; the candidate who asks "what if both indices are the same?" has thought about it.