--- title: "RO 2-056 6.11.2 [basic.contract.eval] Make Contracts Reliably Non-Ignorable" document: p3911r2 date: 2026-01-14 audience: SG21 Contracts,EWG Evolution reply-to: - "Darius Neațu" - "Andrei Alexandrescu" - "Lucian Radu Teodorescu" - "Radu Nichita" - "Herb Sutter" paper-type: proposal --- # RO 2-056 6.11.2 [basic.contract.eval] Make Contracts Reliably Non-Ignorable **Document number**: P3911R2 **Date**: 2026-01-14 **Authors**: Darius Neațu , Andrei Alexandrescu , Lucian Radu Teodorescu , Radu Nichita , Herb Sutter **Audience**: EWG ## Abstract Building on motivation from EWG Kona 2025, this paper proposes a minimal pure extension to the C++26 Contracts facility. This extension addresses the Romanian National Body's (NB) concern by enabling the writing of an individual contract assertion that guarantees the program execution will not continue past the contract assertion if it is violated, regardless of the semantics of other contract assertions. This addition to the C++26 Contracts facility allows reliable use of enforced contract assertions in large codebases with mixed contract semantics and also in hardened libraries. This paper's narrow extension is both necessary and sufficient to address the Romanian NB's concern. It does not preclude, nor co-require, proposals that add properties to "normal" or "always-enforced" contract assertions (such as no-constification, single evaluation, or similar properties) that may achieve consensus in EWG. ## Revision History - [P3911R2](https://wg21.link/P3911R2) (January 2026, after EWG telecon January 8th) - Section §1 (introduction): extend the motivation (see full section §1.1). - Section §3 (proposal): add sections §3.2 (prior work) and §3.3 (ABI implications). - FAQs updates: - Add explicit statement about *not* requiring header dependency (see full section §8.8). - Add new FAQs: §8.11 (tooling), §8.12 (unchanged semantics), §8.13 (predicate evaluation count), §8.14 (previous implementation experience). - Various editorial fixes. - [P3911R1](https://wg21.link/P3911R1) (December 2025, after Kona Meeting) - Focus on implementing the EWG mandate: see sections §1.2 and §2-§5. - Add Acknowledgments section. - Add TL;DR section. - Temporarily remove content in section 7. Wording until EWG agrees on design directions in telecons. - Add §8 Frequently Asked Questions section. - [P3911R0](https://wg21.link/P3911R0) [1] (November 2025, Kona Meeting) - Surface the issue from Romanian NB comment [RO 2-056 6.11.2 [basic.contract.eval] Make contract assertions reliably non-ignorable](https://github.com/cplusplus/nbballot/issues/631). - Iterate through all four possible solutions (labeled as [v1](https://wg21.link/P3911R0#v1-Add-pre-minimal-always-enabled-contracts), [v2](https://wg21.link/P3911R0#v2-Remove-ignore-Semantics), [v3](https://wg21.link/P3911R0#v3-Add-full-Contracts-Properties-Framework), [v4](https://wg21.link/P3911R0#v4-Move-C-Contracts-to-Other-Shipping-Vehicle)), which should be considered in EWG. ## Acknowledgments We thank everyone who provided feedback on drafts of this paper, in particular: Gašper Ažman, Joshua Berne, Peter Bindels, Timur Doumler, Andrei Durlea, Pablo Halpern, Dan Katz, Thomas Köppe, Andrzej Krzemieński, Brad Larson, Lisa Lippincott, Jens Maurer, Jonas Persson, Nina Dinka Ranns, Oliver Rosten, Iain Sandoe, David Sankel, Adrian Stanciu, Ville Voutilainen. ## TL;DR Under the current C++26 Contracts design, if a contract assertion condition is false, the resulting behaviour depends on the evaluation semantics as follows: - `ignore` — continues execution; - `observe` — calls the handler and continues execution; - `quick-enforce` — terminates execution immediately; - `enforce` calls — the handler and terminates execution, unless an exception is thrown in the handler. By design, `pre`, `post`, and `contract_assert` can use any of these semantics. The implementation determines which evaluation semantics apply to each evaluation of the contract assertion. This paper presents two alternative extensions to the C++26 Contracts facility, either of which is sufficient to address the Romanian NB Comment: 1. Introduce "hardened" variations of `pre`, `post`, and `contract_assert` that may only use `quick-enforce` or `enforce` semantics. It is implementation-defined which of these two semantics is used for each contract assertion evaluation. Syntax: `pre` or `pre!`. 2. Introduce "always-enforce" and "always-quick-enforce" variations of `pre`, `post`, and `contract_assert` that may only use `enforce` or `quick-enforce` semantics, respectively, for each contract assertion evaluation. Syntax: `pre` or `pre!` for "always-enforce" ; and `pre` or `pre!!` for "always-quick-enforce". ## Introduction ### Motivation ```cpp // Syntax example for always enforced preconditions - pre! (bang) int critical_access(int* p) pre!(p) { return *p; } ``` This paper is motivated by concerns raised in [RO 2-056](https://github.com/cplusplus/nbballot/issues/631), which highlight the risks of relying on enforcement semantics selected post-definition. Although users should not generally assume that contract assertions are always enforced (depending on project configuration and developer awareness), the core issue is more fundamental: in large-scale, real-world codebases, some contract assertions represent invariants that are sufficiently critical that execution must not continue if they are violated. Under the current C++26 model, such invariants cannot be expressed solely as contract assertions, because enforcement may be disabled or weakened by configuration. This proposal strengthens the C++26 Contracts facility (introduced by P2900R14) by virtue of three key properties that address related but distinct concerns: monotonicity, composability, and local reasoning. The proposed rule is *monotonic* because it only strengthens enforcement guarantees; it never weakens existing guarantees and does not introduce additional permitted executions. Programs that do not opt in are unaffected. Additionally, the proposal is *composable* because a module can state that a given assumption must never be ignored and have that guarantee preserved across translation units, build modes, link boundaries, and runtime configurations. By *local reasoning* we mean semantic guarantees expressed locally in source code. A contract assertion that may or may not be enforced is distinguishable from a comment only after auditing environmental components such as build configuration and other toolchain settings. For some invariants (e.g., security- and safety-critical invariants), non-enforcement constitutes a defect rather than a configuration choice. This proposal allows authors to state which assumptions are semantic requirements rather than configurable hints. Absent such a facility, users must resort to duplicating logic: ```cpp int transmogrify(int x, int y, double z) pre(x > 0) pre(y != 0) pre(!std::isnan(z)) { if (x <= 0 || y != 0 || std::isnan(z)) { cerr << "Fatal contract violation.\n"; abort(); } ... } ``` Such code repeats vital checks once as contract assertions for specification and tooling purposes, and again as ordinary control flow to guarantee termination when said requirements are not met. This duplication is error-prone, inefficient, bulky at source and binary level, prone to divergence (as illustrated by the inconsistency in the example above — the `if` statement should test `y == 0`), and corrosive to *the use of contracts to express program correctness*. Because the contract assertions's evaluation semantics are intentionally not observable from source code, performance-conscious developers cannot elide the `if` in `transmogrify` even if the runtime environment is configured to always enforce the contract assertion. As one workaround begets another, a project-specific trick could be to define and maintain a flag that informs source code whether contracts are always enforced (subject to well-known liabilities, including non-portability, configuration drift, and source-level coupling to build policy): ```cpp int transmogrify(int x, int y, double z) pre(x > 0) pre(y != 0) pre(!std::isnan(z)) { // Project-specific flag approximating contract enforcement state #if !CONTRACTS_ALWAYS_ENFORCED if (x <= 0 || y != 0 || std::isnan(z)) { cerr << "Fatal contract violation.\n"; abort(); } #endif ... } ``` All of the issues discussed above are eliminated by a monotonic, opt-in enforcement guarantee with local reasoning. The initial ([P3911R0](https://wg21.link/P3911R0) [1]) version of this paper discussed four potential solution approaches: 1. Add a way to write a contract assertion that will always be enforced in all cases (regardless of the currently active contract semantics). 2. Remove "ignore" (and, as was intended, "observe") contract semantics from the C++ Working Draft. 3. Adopt all of [P3400R2 Controlling Contract-Assertion Properties](https://wg21.link/P3400R2) [3] — the full C++ Contracts properties framework. 4. Remove the C++26 Contracts facility from the C++ Working Draft introduced by [P2900R14](https://wg21.link/P2900R14) [2]. The R0 revision of this paper recommended pursuing option 1. It is purely additive to C++26 Contracts, pulls forward into C++26 one specific capability from the post-C++26 direction described in P3400R2 that addresses the current concerns, and does so in a forward-compatible way with P3400R2. ### Overview of R1 revision: Following the EWG Kona 2025 direction In Kona 2025, [EWG encouraged work](https://github.com/cplusplus/nbballot/issues/631#issuecomment-3488277609) in the direction proposed in D3911R0 (now [P3911R0](https://wg21.link/P3911R0) [1]): > Poll: RO 2-056 6.11.2 [basic.contract.eval] Make contracts reliably non-ignorable — we want to pursue a change for C++26 as proposed in one of the four options listed in D3911R0. > > | SF | F | N | A | SA | > | --- | --- | --- | --- | --- | > | 18 | 25 | 22 | 7 | 0 | > > Result: consensus for change Option 1, which proposes making contracts reliably non-ignorable by adding a syntax that ensures contract assertions have guaranteed effects, was the main focus of the EWG discussion. EWG raised three important additional observations regarding Option 1: - It is **a pure extension** that does not affect existing C++26 Contracts semantics and pulls forward a **specific narrow capability** already considered and encouraged in P3400R2 for post-C++26 Contracts evolution. - It may also **address other NB concerns**, notably enabling the implementation of the C++26 hardened standard library using C++26 Contracts. (For example, via `#ifdef` guards, such as `#ifdef __hardening` / `pre(idx < size())` / `#endif`; today, libraries that do this put nonstandard code in the guarded section.) - It should apply uniformly to **all three contract assertions** — `pre`, `post`, and `contract_assert` — as requested by several EWG participants. This ensures consistent capability across all contract assertion types. ## Scope ### Design constraints per EWG mandate To follow EWG direction, increase consensus, and avoid scope creep, this revision adopts the following design constraints: 1. **Scope: Option 1 only.** We have removed options 2, 3, and 4, which EWG deemed as unviable. 2. **Pure extension.** This paper proposes a pure extension to the C++26 Contracts facility from the post-Kona C++ Working Draft. It does not change the existing semantics of `pre(condition)`, `post(ret: condition)`, or `contract_assert(condition)`. 3. **Minimal semantics delta.** This paper does not propose additional changes beyond providing a way to spell "always-enforced" contract assertions in source code, which is enough to satisfy the Romanian NB's concern and which EWG encouraged. To avoid scope creep, it does not propose additional properties of "always-enforced" contract assertions (e.g., no-constification, single evaluation, or similar properties) that differ from existing C++26 Contracts and may achieve EWG consensus independently. The Romanian NB expresses no position on the inclusion of such additional properties. See §8 Frequently Asked Questions for further discussion of additional design questions. ### Key open questions addressed by this paper We identify the following open questions: Q1. Should "always-enforced" contract assertions **support `enforce` and/or `quick-enforce` semantics**? See section §4. Q2. What **syntax** should be used? See section §5. ## Proposal: Add source syntax for minimal always-enforced contract assertions This paper proposes introducing a **minimal syntax to mark certain contract assertions as "always-enforced" in source code (see §4)**. This additional syntax is placed between the contract keyword and the condition (see §4 and §5 for the proposal): | Case | Syntax | | --- | --- | | Unchanged syntax | `pre(x != 0)` | | Added "always-enforced" syntax | `pre` *placeholder-tokens* `(y != 0)` | A "`pre` *placeholder-tokens* `(condition)`" assertion is always enforced, independent of any other contract semantics selected for `pre (condition)`. The same syntax choice applies to `post` and `contract_assert`. This design represents a balanced compromise: it preserves configurability while ensuring selected contract assertions are reliably checked. No future extensions are precluded. ### Existing practice There is a substantial body of existing practice that motivates "always-enforced" contract assertions, demonstrates their utility, and makes the model familiar to users. Many production codebases ship an always-on assertion (separate from `assert`, which is sometimes-on by means of the `NDEBUG` macro). Such mechanisms, commonly named `CHECK`, `VERIFY`, or `ALWAYS_ASSERT` in existing codebases, provide run-time validation of key conditions even in production: they verify the condition and do not continue execution if it does not hold. They are widely used as safety checks for preconditions, i.e., as intentionally redundant code that has no observable effect in correct program executions, but deterministically prevents execution from continuing in incorrect executions. Such mechanisms may also be used outside an assertion context, where they are not redundant. Below, we present a selection of representative, widely used examples that leverage non-continuing (terminating) enforcement semantics in production: - **Google Abseil**'s [CHECK](https://abseil.io/docs/cpp/guides/logging#CHECK) ("terminates the process" in all builds; paired with debug-only `DCHECK`) is used in a plethora of Google and third-party projects, notably including **Protocol Buffers**, **glog**, **gRPC**, **Chromium**, and **TensorFlow**. - **Facebook Folly**'s [XCHECK](https://github.com/facebook/folly/blob/main/folly/logging/xlog.h) (always-on — "this crashes the program"). - **WebKit**'s [RELEASE_ASSERT](https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/Assertions.h) ("crashes with info"; paired with `ASSERT`). - **LLVM**'s [cantFail](https://llvm.org/doxygen/llvm_2Support_2Error_8h.html) (several overloads — "report a fatal error"). - **Mozilla Gecko**'s [MOZ_RELEASE_ASSERT](https://github.com/mozilla/gecko-dev/blob/5836a062726f715fda621338a17b51aff30d0a8c/mfbt/Assertions.h#L566). - **Apache Arrow**'s [ARROW_CHECK](https://github.com/apache/arrow/blob/3dc982183db45ced57ef1565e022dcb647a00745/cpp/src/arrow/util/logging.h#L67). Note: The quoted phrases above are taken verbatim from the respective project documentation. Experience shows that defining a project-specific assertion facility (or using an established one such as Abseil or Folly) is a mark of project growth and maturity. Such facilities almost always include an API that deterministically terminates execution when a boolean condition evaluates to false. Externally-controlled assertions and always-active checks rely on the same underlying mechanics, which is why mature codebases commonly pair them: a debug-only assertion alongside an always-fatal check for essential invariants. Absent a reliable facility that terminates execution when a condition is false, users must duplicate logic by first writing an assertion that may or may not be active, then adding manual code to test the condition again and terminate on failure. A single, always-available check facility avoids that duplication, keeps intent obvious, and reduces divergence across configurations. ### Prior work The following papers provide relevant prior work and historical context for "always-enforced" contract assertions: - [P3640R0: Make contracts reliable by default](https://wg21.link/P3640R0) [8]. - [P1429R3: Contracts That Work](https://wg21.link/P1429R3) [9]. - [P1332R0: Contract Checking in C++: A (long-term) Road Map](https://wg21.link/P1332R0) [10]. Existing implementation experience for these proposals is discussed in section §8.14. ### ABI implications The C++26 Contracts facility is designed to preserve ABI backward-compatibility when adding function contract specifiers. [P2900R14](https://wg21.link/P2900R14)'s Principle 16 ("No ABI Break") states: "*A conforming implementation should be able to guarantee that adding function contract specifiers to an existing function preserves ABI backward-compatibility.*" This ensures that code can add function contract specifiers incrementally without requiring recompilation of client code. P2900R14 does not explicitly discuss the effects of changing or removing existing function contract specifiers. It is this particular scenario, namely removing an "always-enforced" contract assertion, which deserves special attention. Consistent with P2900R14's design intent, this proposal takes a conservative and future-proof approach and stipulates that changing or removing a function's contract specifiers is likewise intended not to require recompilation of already-compiled callers. To ensure no ABI break, callers are not permitted to assume control flow does not continue if a `pre!` or `post!` function contract specifier is violated. Consider: ```cpp // Using one of the proposed syntaxes as example. int fun(int x) pre!(x != 0); // gun() - perhaps located in a different library. int gun(int y) { if (y == 1) { fun(y - 1); std::printf("Hello, world!\n"); } return 0; } ``` If `pre!(x != 0)` were a semantic guarantee that execution cannot continue past the call, then an optimizing compiler could assume that execution does not continue execution past the call `fun(y - 1)` and eliminate the call to `printf` entirely because it's on an unreachable code path. If later on the owner of `fun` changes its declaration to use `pre` instead of `pre!` (or remove the function contract specifier entirely), `gun` must be recompiled; otherwise, the program may exhibit undefined behavior due to assumptions made during caller's compilation that are no longer valid. In order to stay true to the design goals of the C++26 Contracts facility, this proposal stipulates that `pre!` is **an enforcement, not an assumption**. An implementation is not permitted, for the purposes of caller-side compilation, to treat violation of an "always-enforced" contract assertion as implying that execution cannot continue past a function call. For all purposes relevant to caller-side compilation, `pre!` shall be treated equivalently to `pre`, and `post!` equivalently to `post`. This choice is intentionally conservative with respect to ABI stability and implementation freedom. It benefits from reusing the extensive analysis of P2900R14 and leaves room for future refinements. Also, this proposal does not mandate where enforcement is performed (caller or callee), preserving the implementation latitude envisioned by P2900R14. ## Design choice 1: Should "always-enforced" contract assertions support `enforce` and/or `quick-enforce` semantics? For this design choice, the following major options were considered: - Support only one of the "enforce" or "quick-enforce" contract semantics? - Support both explicitly selectable in the source code? - Do what a hardened standard library does (i.e., leave it implementation-defined)? During the EWG discussion and on-time papers in Kona, such as [P3835R0](https://wg21.link/P3835R0) [4], it appears there are three large, partially overlapping groups: - those who want to specify "always enforce" semantics in source code; - those who want to specify "always quick-enforce" semantics in source code; and - those who want to specify "never ignore or observe, without a preference for enforce or quick-enforce" contract semantics in source code. Either option presented in sections §4.1 or §4.2 (see below) would satisfy the Romanian NB’s concern. More generally, if EWG identifies another option with consensus support that guarantees program execution does not continue (see §8.10) when that contract assertion is violated (including, but not limited to, never being subject to ignore or observe semantics), the Romanian NB would accept that as satisfactory. ### Enforcement option 1: Support "always-contract-terminate", and leave calling a violation handler implementation-defined *This option* makes **a single "always contract-terminate" syntax** selectable in source code, leaving it implementation-defined whether a contract-violation handler is invoked. See §5 for *placeholder* syntax options. | Case | Syntax | | --- | --- | | Unchanged | `pre (x != 0)` | | Added "always-contract-terminated" syntax | `pre` *terminate-tokens* `(y != 0)` | A "`pre` *terminate-tokens* `(condition)`" shall always be enforced regardless of other semantics that may be used for `pre (condition)`, and the implementation shall define whether or not a contract-violation handler is called (a terminating semantics is guaranteed to be used). Note that the same design choice applies to `post` and `contract_assert`. ### Enforcement option 2: Support both enforce and quick-enforce contract semantics *This option* provides **two distinct placeholders**, allowing the programmer to express **either "always enforce" or "always quick-enforce"** in source code for a given contract assertion. | Case | Syntax | | --- | --- | | Unchanged | `pre (x != 0)` | | Added "always-enforced" syntax | `pre` *enforce-tokens* `(y != 0)` | | Added "always-quick-enforced" syntax | `pre` *quick-enforce-tokens* `(y != 0)` | A "`pre` *enforce-tokens* `(condition)`" is always enforced, and a "`pre` *quick-enforce-tokens* `(condition)`" is always quick-enforced, regardless of any other contract semantics selected for `pre (condition)`. Note that the same design choice applies to `post` and `contract_assert`. ## Design choice 2: What syntax should be used? Several alternatives were considered. This paper proposes two concise syntax choices (§5.1 and §5.2 — see below) that are forward-compatible with future directions, such as [P3400R2](https://wg21.link/P3400R2), without precluding future library-based assertion-control mechanisms (see §8.8). Either option presented in sections §5.1 or §5.2 (see below) would satisfy the Romanian NB’s concern. More generally, if EWG identifies another option that has consensus support, the Romanian NB would accept that, provided that the contract semantics guarantee the program code does not continue execution after a violation (see sections §4 and §8.10). The Romanian NB requests only a narrow extension that allows a contract assertion to be marked as enforced in source code. Instead of inventing a new syntax, this paper follows the design direction previously discussed and encouraged in EWG. ### Syntax option 1: Use