Before relying on tail-call elimination for unbounded input, what must you establish?

**"Safe reliance" means a written guarantee, not a passing test.** Before you let stack safety depend on tail-call elimination, you need a statement from the language or runtime contract that tail calls in the shapes you use are eliminated, in the build modes you ship. An experiment that ran ten million iterations without failing is evidence about one build, one input size, and one call shape; it is compatible with a best-effort optimization that will disappear when a debug build ships, when an inlining decision changes, or when the call is dispatched dynamically after a refactor. The distinction to hold in your head: a guarantee is a promise about all future executions; a green test is an observation about one past execution. **Establish the scope of the guarantee, not just its existence.** Guarantees are usually narrower than the headline. Check, in order: 1. **Self-recursion only, or general tail calls?** If only direct self-recursion is covered, mutual recursion between two ledger-walking helpers still grows the stack, and an innocent refactor that splits one function into two can convert a safe program into an unsafe one. 2. **Which build modes?** If the promise attaches to an optimization level, debug builds and interpreter tiers are outside it — and those are exactly the modes used when reproducing a bug against production-sized data. 3. **Which syntactic contexts?** A call inside an exception-handling or scoped-cleanup region is not in tail position at all, because the handler is pending work. Wrapping a recursive body in a resource scope for "safety" can silently remove the property. 4. **Static or dynamic target?** A call through a function value or an overridable method may fall outside a guarantee that requires a statically known callee. **Make the property hard to break by accident.** Tail position is fragile under ordinary maintenance: adding a log line after the recursive call, wrapping the result to attach metadata, changing `return step(rest, acc)` to `return validate(step(rest, acc))` — each of these removes the property with no diagnostic anywhere, and the regression only surfaces at production input sizes. If your target offers a compiler-checked way to assert tail position, use it, so the build fails instead of production. If it does not, the mitigations are a comment stating the invariant at the call site, a test that runs an input far beyond realistic scale (so a lost guarantee fails in CI rather than at 3 a.m.), and a review habit of treating any edit to that return statement as load-bearing. **Decide what you do when there is no guarantee.** On a target that never eliminates tail calls, the accumulator rewrite is a style preference, not a safety measure, and you have three honest options: bound the depth by construction (recurse over a structure whose depth is logarithmic or otherwise capped, and iterate over the unbounded dimension); process the unbounded stream in fixed-size chunks so depth is bounded per chunk; or write the unbounded traversal as a loop and keep recursion where it is genuinely clearer and provably shallow. Choosing by *which dimension is unbounded* is the judgment being tested: a ledger of unknown length is unbounded in count, so the count dimension must not be the recursion dimension. **The porting hazard is the senior-level part of this question.** In traditions where elimination is guaranteed, recursion *is* the loop, and idiomatic code recurses over arbitrarily long inputs without anyone thinking about depth. Engineers arriving from that background carry the habit, and on a target that declines elimination the habit is a latent production failure that small test data will never reveal. The team-level answer is not "don't write recursion" — it is to name the boundary explicitly: which of our targets guarantee it, what the depth bound is on the ones that do not, and what happens in review when a recursive traversal takes an unbounded input. **How to say it in an interview.** Lead with the guarantee/observation split, then the scope questions, then the fragility under refactoring, then what you do when the answer is no. A candidate who says "I checked the spec, and it covers self-recursion in all build modes, so I bounded the mutual-recursion case separately" is demonstrating precisely the judgment the question is aimed at. A candidate who says "I tested it with a big input and it was fine" has answered a different, weaker question.