A library operation documents that its argument must be a non-empty collection, and a caller passes an empty one. Whose defect is that, and how do Eiffel, Racket, Kotlin and Rust each express and enforce that obligation differently?

## The idea Design by Contract, introduced with Eiffel, models the relationship between a routine and its callers as a commercial agreement. Each side has obligations and each side gets benefits, and the obligations are written into the code rather than into prose. - **Precondition** — what the caller must guarantee before the call. Obligation of the caller, benefit to the implementer, who may assume it without checking. - **Postcondition** — what the routine guarantees on return, provided the precondition held. Obligation of the implementer, benefit to the caller. - **Class invariant** — a property of the object that holds between externally visible operations. Obligation of every operation of the class, benefit to every client. The non-obvious consequence is the *no double-checking* rule: if a condition is a precondition, the implementer should not also validate it and raise a friendly error. Two checks means neither side owns the condition, and the error you get depends on which check ran first. ## Blame is a design decision, not an error message What separates real contract systems from an assertion sprinkled in a function body is whether the violation identifies a *party*. **Eiffel** compiles the clause into the routine header. A failed `require` produces a precondition violation whose semantics are: the client called me wrongly. A failed `ensure` says: I failed to deliver. The exception type itself carries the accusation, and Eiffel's teaching material is explicit that a supplier which defensively re-checks its own preconditions has misunderstood the model. **Racket** goes further and makes blame first-class. `contract-out` attaches a contract to a module boundary, and every boundary has two parties: the module that provides the value (positive) and the module that uses it (negative). A violation message literally names the guilty module. The deep part is *higher-order* contracts. If you take a function as an argument and the contract on that argument's own parameter is violated, the fault is not with the module that supplied the callback — it is with you, the module that invoked it. Racket flips the polarity of nested arrow contracts to get this right, which is why a contract system for first-class functions cannot be a simple boolean assertion at the entry point: the check is deferred until the callback is applied, and the wrapper must remember whom to accuse. **Kotlin** ships the diagnostic half without the party half. `require(x.isNotEmpty())` raises `IllegalArgumentException` — a bad argument — and `check(state != null)` raises `IllegalStateException` — a bad receiver state. That split encodes exactly the caller-versus-implementer distinction in the *exception type*, but the two functions are ordinary library calls, always evaluated, with no relation to any inherited specification. **Rust** answers by refusing to have a runtime question. `NonZeroUsize`, or a hand-rolled `NonEmpty<T>` whose only constructor is a fallible `from_vec`, moves the obligation to the type. The caller proves non-emptiness once, at the point where the failure is actually recoverable and where there is real context to report, and the library function's signature is then total: every value of the parameter type is acceptable. Nothing can be stripped, nothing can drift out of date with the documentation, and there is no blame because there is no violation. ## Contracts versus input validation The most common professional error is using contract machinery on untrusted input. A precondition says *this must be true or the program has a bug*. Data arriving from a network request, a file or a user form can perfectly legitimately be empty; rejecting it is normal control flow that returns a 400 or an error value, not an assertion failure. The test is simple: if a well-behaved system can produce this input, it is validation, and it belongs in ordinary code that stays in the binary. If only a defect can produce it, it is a contract. This matters because several languages allow contract checks to be compiled out, and because contract failures should be unrecoverable by design: catching a precondition violation and continuing means continuing with a program you have just proved wrong. ## What a strong answer sounds like Name the party first (the caller), then show that you know the difference between a language that mechanises blame (Eiffel, Racket), a language that only mechanises the diagnosis (Kotlin), and a language that dissolves the problem in the type system (Rust, and Ada's subtype predicates in the same spirit). Finish with the boundary rule: contracts govern cooperating code, validation governs the outside world.