In a linear search, why is a zero-valued record a bad way to signal 'not found'?

## Two outputs pretending to be one Every search answers two questions at once: **did anything match**, and **which element was it**. These are independent. The moment you encode the first into the value space of the second, you have created an ambiguity that the type system cannot help you with and that reviewers must catch by eye. Returning a zero-valued (or empty, or default-constructed) record for "not found" is the most common form of this mistake, because it is so convenient — the caller gets something shaped like a record and can dot into it without checking anything. ## The three states that collapse into one Walk a feature-flag lookup that scans a list of flag records for a matching name and returns a zeroed record when the scan falls off the end: 1. **The flag is absent from a populated list.** Someone typo'd the name, or the flag was retired. Expected, benign, worth a warning. 2. **The list itself is empty.** The config never loaded, or loaded into the wrong place. This is an operational failure, and it is the state you most want to be loud about. 3. **The flag is present and switched off.** Entirely normal, and the whole point of having flags. All three return a record whose enabled field is false. The caller writes the obvious branch, takes the old code path, and nothing anywhere logs a problem. State 2 — the outage — is indistinguishable from state 3 — the healthy steady state. That is why this is a bug and not a style preference: the failure mode is *silence*. ## What a good contract looks like There are three defensible shapes, and the choice is about the calling code, not about taste. **Return a position, reserve an impossible one for a miss.** A scan that yields an index can signal absence with an index outside the valid range — most conventionally, one below the first valid index. It is cheap, it composes with subsequent indexing, and the sentinel is genuinely impossible to confuse with a real position. Its weakness is that nothing forces the caller to check; the discipline lives in review. **Return an explicit present/absent result.** A wrapper the caller must unwrap before reaching a value moves the check from convention to structure — forgetting it becomes a compile-time or at least an obvious runtime event rather than a silent default. This is the modern default where the language offers it, and the reason it is worth the extra type. **Return the value plus a separate found indicator.** Two outputs, honestly separated. It works, and it is what several mainstream runtimes settled on — Go's comma-ok lookups and C++'s end-iterator convention are two different answers to the same design question, and both keep the "was it found" bit strictly outside the value. What is *not* defensible for an ordinary lookup is raising an error. A miss is a normal, expected outcome of asking whether something is present; reserving exceptions for it makes routine control flow expensive and noisy, and pushes callers toward swallowing the error broadly. ## The empty-collection question Does scanning an empty collection deserve a different result from a genuine miss? At the level of the search itself: no. Zero elements examined, nothing matched, that is a miss and the contract should say so plainly — no special case, no error. Special-casing empty input inside the scan is a common over-correction that adds a branch and answers a question the caller did not ask. But the layer above almost always cares. "Configuration was never loaded" and "configuration was loaded and this key is absent" are different operational facts, and the right place to distinguish them is at load time — a loaded-successfully flag, a startup assertion, a metric on collection size — not inside a search that has no idea how the collection came to be empty. ## Which match wins One more clause of the contract, usually left implicit: a sequential scan returns the **first** match in iteration order. When duplicates are possible, callers depend on that fact whether or not it was ever documented. Reversing the iteration for a micro-optimization, splitting the scan across workers, or switching to a structure with a different traversal order will silently change which record comes back. If first-match-wins is guaranteed, write it down; if it is not, say the result is unspecified among duplicates and make sure that is actually true. ## Reviewing for it The review heuristic is short. Look at the value the search returns on a miss and ask: *could a legitimately stored element ever be equal to this?* If yes — zero, empty string, empty record, false — the contract is ambiguous and the ambiguity will surface as an outage that looks like normal operation.