P4011R0 | Redefining narrow contract | Matthias Kretz | EWG | 2026-02-12

I am a bot, and this action was performed automatically. Please contact the moderators if you have questions or concerns.

Another day, another contracts paper. At this rate we'll have more papers about defining what a contract is than papers about actual contracts.

This paper is two pages. I've seen longer commit messages.

The paper identifies a real problem but introduces a new one. The word "erroneous" is doing too much work.

Under C++26, "erroneous behavior" already has formal semantics - it means "well-defined but incorrect, implementations may diagnose." Kretz uses "erroneous" informally. He says explicitly that his definition "does not have to imply erroneous behavior." But then Section 5 connects it to EB anyway:

This is what we expect of EB: it is still detectable as a bug in the program, but the program can continue without invoking UB.

So which is it? Three possible readings:

1. "Erroneous" maps to formal EB. Then narrow = "some inputs trigger erroneous behavior." But EB has specific rules about what implementations can do, and those rules might not apply to all precondition violations.

2. "Erroneous" is a new informal category - "this call is a bug" - with no formal behavioral consequence. Then we've replaced one gap (what happens when you violate a wide-but-preconditioned function?) with another (what does "erroneous" mean if it's not EB and not UB?).

3. "Erroneous" means whatever the contract annotation says, and the evaluation semantics (ignore, observe, enforce) determine the behavioral consequence separately. This is actually the most useful reading, but the paper doesn't commit to it.

The deeper issue: the old definition was operational. You could look at the spec and ask "can this function invoke UB?" and get a yes/no answer. The new definition requires knowing author intent about which inputs are "erroneous." That's a specification question, and the standard doesn't currently have a way to express it without either UB or EB.

R0 problems. But the problem it's trying to solve is real.

Edit: u/lakos_rule_fan raises a good point below about noexcept implications. That might be the bigger omission.

Worth zooming out from the definitional debate for a second, because the paper buries its own best insight in a one-sentence consequence:

A human - and potentially also a tool - can tell whether a specific call to a function is a bug in the program or not.

This is actually what we want from a contract definition. Not "what happens to the program" (UB, EB, trap, exception) but "is the caller wrong." Those are different questions. The first is about implementation consequences. The second is about API semantics.

For library documentation, the second question is the one I need answered. When I write docs for sqrt(x), I say "x must be non-negative" - I don't say "passing a negative x invokes undefined behavior." The user needs to know they're wrong. What the implementation does about it is a separate axis.

If you adopt Kretz's definition, static analysis tools get a clearer job description: flag calls where the input can be shown to be erroneous in the precondition sense, regardless of whether the runtime consequence is UB, trap, or a polite error message. That's better for tools like clang-tidy and PVS-Studio than the current definition, where "wide contract" means either "accepts all inputs" or "accepts all inputs because it validates internally" and the tool can't distinguish the two.

Boost.Contract dodged this entire question by having preconditions always throw on violation.

This is the reason why some say an unconditionally enforced precondition check is not a contract check anymore.

Those "some" are right, and the paper doesn't engage with their actual argument.

N3248's definition isn't broken - pre!() is the thing that's weird. If you unconditionally enforce a precondition check, you've transformed a specification element into an implementation element. The function now validates its input as part of its observable behavior. That's not a narrow-contract function with a safety net - it's a wide-contract function that rejects bad input. N3248 correctly reflects this transformation.

Three points:

1. A precondition is a promise the caller makes. Whether the callee checks it is an implementation detail. pre!() makes the check part of the function's guaranteed behavior. At that point, the "precondition" is really an input validation step.

2. The paper says we need to "decouple from behavior." But behavior is the discriminant. Narrow means the implementation makes no promises about bad input. Wide means it handles everything. An enforced precondition handles everything - with a specific response. That's wide.

3. The committee spent years getting P2900 through SG21 with layered evaluation semantics (ignore, observe, enforce, quick_enforce). The whole point was that the same annotation can have different behavioral consequences depending on build configuration. That's already the decoupling Kretz wants. The definition doesn't need to change - the understanding of what pre means needs to account for enforcement modes.

While we're redefining things, can someone redefine "undefined behavior" to mean "the compiler does what you meant, not what you wrote"?

From a compiler optimization standpoint, there's a subtlety the encounter thread above is dancing around without naming.

When a function has a narrow contract under the N3248 definition, compilers can assume the precondition holds at every call site. If f(x) requires x >= 0, the compiler can propagate that constraint after the call - dead branch elimination, value range tightening, the works. This is because violating the precondition is UB, and compilers are allowed to assume UB doesn't happen.

If we redefine narrow to include functions where violation is erroneous-but-not-UB (enforced preconditions, EB), compilers lose that assumption for a subset of "narrow" functions. The compiler can't assume x >= 0 after calling a function that traps on x < 0 - because the trap is defined behavior. The program might trap and then continue (depending on the violation handler).

This doesn't mean the new definition is wrong. It means the optimization story bifurcates: "narrow with UB" lets compilers assume, "narrow with enforcement" doesn't. The paper should flag this because it affects how implementers think about the distinction, and EWG includes people who care about codegen.

Wait, Kretz? Isn't he the simd guy? How did he end up in the contracts tarpit?

Here "erroneous" does not have to imply erroneous behavior (but see below).

Then, two paragraphs later:

This is what we expect of EB: it is still detectable as a bug in the program, but the program can continue without invoking UB.

Pick one. Either "erroneous" in the definition maps to the standard's EB concept - in which case, say that and accept the implications - or it doesn't, in which case you've introduced an informal category with no formal behavioral semantics.

The g() example in Section 5 is particularly telling. The function has a precondition AND a defined fallback (return 0 for negative input). Under the proposed definition: narrow. Under N3248: depends on whether the fallback means no UB. Under the EB framework: erroneous behavior - well-defined but incorrect. Three frameworks, three potentially different answers for the same function.

R0 is fine for raising the question. But the answer needs to land before EWG can do anything with this.

Placeholder changelog. Placeholder straw polls. Two pages of actual content. Is this a paper or a pull request description?