When a compile-time expansion substitutes one argument expression at two places in its body, what does the caller lose?

## The mechanism: expression in, expression out A compile-time **expansion** replaces a call to a macro-like construct with a copy of that construct's body, substituting each **argument** wherever the matching parameter appears. What is substituted is the argument's *expression*, not the value that expression would produce - expansion runs before the program is compiled, so nothing has been evaluated and there is no value to copy. If the parameter appears at two places in the body, the caller's expression now stands at two places in the compiled program, and each one is a separate evaluation at run time. This is the half of the hygiene problem that is about **evaluation count** rather than about names. The other half - a binding the expansion introduces colliding with one the caller had - has the same root cause: an expansion is not a function call, and everything the caller's intuition assumes comes from calls. ## Counting the evaluations honestly Take a body of the shape `if a > b then a else b`, called with an argument for `a` that has an observable effect. Trace the branch that actually fires: 1. The guard `a > b` evaluates the substituted expression once. 2. If the guard is **true**, the `then` branch evaluates it a second time - two evaluations. 3. If the guard is **false**, the `else` branch never mentions it - one evaluation. So "it runs twice because it appears twice" is as wrong as "it runs once because a call evaluates its argument once". The rule is: **once per occurrence that control flow reaches**. | Occurrence in the body | Reached when | Effect on an argument with a side effect | |---|---|---| | inside the guard | always | the effect happens | | inside the taken branch | guard selects it | the effect happens again | | inside the untaken branch | never on this run | no effect at all | ## What the caller loses - **Repeated side effects.** An argument that advances a cursor, consumes an item, appends to a log or mutates shared state performs that effect again. - **Repeated cost.** An expensive argument is paid for more than once, invisibly, at a call site that looks like one call. - **Disagreeing results.** This is the sharpest one. If the argument yields a different value on the second evaluation, the value the expansion *returns* is not the value that *won* the comparison. The construct's own contract is broken and the call site shows nothing. - **Order surprises.** With several multiply-used parameters, the interleaving of their effects is decided by the body's text, not by the order the caller wrote them. None of this produces a diagnostic. The program compiles, runs, and is wrong on the runs where the extra occurrence is reached. ## The bind-once fix Evaluate each multiply-used argument exactly once into an introduced binding, then have the body read that binding: 1. At the top of the expansion, declare one binding per multiply-used parameter. 2. Initialise each from the substituted expression, in the order the caller wrote the arguments. 3. Replace every occurrence of that parameter in the rest of the body with the binding. Now the count is exactly one, on every path, and the value compared is the value returned. ## Why the fix drags the naming problem back in The fix introduces a binding into the caller's block - which is precisely the setting in which **accidental capture** happens. If the introduced binding is called something ordinary, a caller that already has a name of that spelling is silently shadowed, and any argument text mentioning that name now resolves to the expansion's temporary. So bind-once is only safe when the introduced name is **freshly generated**: a name derived per expansion that no caller's source could contain. The two halves of hygiene are not independent rules; solving one correctly requires the other. ## When repeated occurrence is acceptable - The parameter appears exactly once in the body - nothing to repeat. - Every occurrence lies on mutually exclusive paths **and** the construct's contract does not depend on the values agreeing. - The argument is a plain name or literal. This is the weakest of the three, because the macro author does not choose the argument: the caller does, and the next caller may pass a call. Where expansion facilities differ is in how much help they give: some evaluate or bind arguments for you and generate the temporaries' names, others substitute text and leave both problems entirely to the author. The conservative discipline - bind once, name freshly - is correct under either. ## What an interviewer is listening for That you say "an expansion is not a call" and then reason from it: count the evaluations per path rather than per occurrence, name disagreeing values as the real bug rather than just wasted work, propose bind-once, and notice unprompted that the temporary you just introduced needs a generated name.