In a static type checker, what is the difference between soundness and completeness?

## The two words, precisely Think of the checker as a classifier over programs, with the ground truth being "would this program actually commit a type error on some execution?" - **Sound**: if the checker accepts a program, the program does not commit a type error. Equivalently: every unsafe program is rejected. A sound checker has **no false negatives** — nothing unsafe slips through. - **Complete**: if a program does not commit a type error, the checker accepts it. Equivalently: no safe program is rejected. A complete checker has **no false positives** — nothing safe is blocked. The classic slogan for soundness is that well-typed programs do not go wrong. The slogan carries a hidden clause: *go wrong in the ways this particular type system models*. A sound system for absence still permits a wrong amount to be paid; soundness is relative to the property the types express, never to correctness in general. ## Why you cannot have both Whether an arbitrary program ever performs a given operation on a given value is undecidable in general — the same wall that makes non-trivial semantic properties undecidable. A checker must terminate and must answer, so it approximates: it either errs toward rejecting some safe programs (sound, incomplete) or toward accepting some unsafe ones (unsound, more permissive). This is not a defect of any particular tool. It is the shape of the problem, and it is the same tradeoff every other static analysis makes; type checking is just the case where the industry has settled on a very specific, very fast approximation. ## Where real checkers choose unsoundness on purpose Mainstream checkers lean toward usability. The recurring deliberate holes are worth naming, because knowing the list is what separates a senior answer from a textbook one: - **Unchecked assertions.** A construct that tells the checker "treat this value as this type" with no verification. It is the escape hatch by which every other guarantee can be voided in one line. - **Data from outside the program.** Parsed payloads, configuration, stored records. The declaration is an assumption; nothing verifies it unless code does. - **Interop with unannotated code.** Values crossing in from a region the checker does not analyse. - **Mutable containers used covariantly.** Many systems accept treating a container of a subtype as a container of a supertype, which is fine for reading and unsafe for writing. - **Reflective or dynamic member access.** Constructing a member name at run time defeats a static model of members. - **Out-of-band mutation.** A field narrowed by a branch condition can be changed by something else before the narrowed use — a classic gap between what the checker proved and what happens. ## Why full soundness is not automatically better A strictly sound checker rejects safe programs, and every rejection lands on a developer under deadline. The observed response is not to restructure the code; it is to reach for the escape hatch. A codebase that is sound-in-theory and riddled with assertions has a *worse* safety profile than an honestly unsound one, because the holes are unlabelled and the team believes the guarantee holds. So the engineering question is not "is this checker sound?" but "is its unsoundness enumerable, greppable, and audited?" ## An audit worth copying A 4-person team owning a payroll engine investigated a partial-failure rollback that credited 47 employees twice. The root cause was one unchecked assertion added months earlier to silence three errors when a record shape changed; the value asserted to be a settled posting was in fact a draft, and the compensating routine happily reversed it. The response was not to demand a sounder checker. It was to make the unsoundness visible: an audit found 74 unchecked assertions across 1,163 files, 9 of them on money-handling paths; 2 of those 9 were wrong. The team then required every assertion to carry a one-line justification and forbade them entirely inside the money core, where validation functions replaced them. The point of the story is the reframing — the checker's holes are a managed inventory, not a mystery. ## Answering it well Give both definitions in the accept/reject direction, map each to false negatives and false positives, say plainly that both at once is impossible, and then get concrete about which holes your checker has and how the team keeps them countable. Avoid claiming that any mainstream checker is fully sound, and avoid dismissing unsoundness as sloppiness — it is a deliberate, defensible tradeoff that turns bad only when it is undocumented.