Contracts in the C++ standard. In my lifetime. I genuinely did not think I would see this day. What's next, networking?

12 SA votes in EWG. Twelve. And they shipped it anyway. Committee gonna committee.

The fundamental tension in this paper is one nobody in this thread is going to talk about because the sarcasm-to-signal ratio is approximately 15:1, so let me be the signal.

P2900 standardizes contract predicates that are evaluated at runtime. The predicate in pre(ptr != nullptr) is a C++ expression evaluated in the caller's context. Here's the thing: if ptr is a dangling pointer, evaluating ptr != nullptr is undefined behavior. The contract predicate - the thing you wrote to detect the bug - triggers UB before it can catch anything.

The committee voted at Hagenberg (9|7|9|22|19) against reducing UB in contract predicates. The safety feature has undefined behavior and the committee voted to keep it that way.

The argument is coherent if you accept the premise: contract predicates are C++ expressions, C++ expressions can have UB, and special-casing contracts would require defining a "safe subset" of expressions that nobody agrees on. Fair enough.

But the consequence is that contracts don't improve the worst case. They improve the average case - you catch the nulls and the out-of-ranges and the precondition violations that are straightforward to check. The lurking UB - the dangling pointers, the data races, the type-punning - remains invisible to the contract system because evaluating the check for those conditions is itself UB.

This is probably the right tradeoff. But the marketing of "contracts improve safety" needs an asterisk the size of section 6.8.4.

Edit: some people are reading this as "contracts are bad." I'm not saying that. I'm saying the gap between what contracts promise and what they deliver is larger than the abstract suggests, and the committee made a deliberate choice to keep that gap.

I give it two standards cycles before someone proposes P3900 "Contracts for Contracts" - a mechanism for asserting preconditions on your preconditions

Can someone ELI5 what this actually does? I started learning C++ eight months ago and this paper is like 200 pages and everyone here seems either furious or ecstatic and I can't tell which reaction is correct

Meanwhile in Rust, the type system prevents most of these bugs at compile time. No runtime checks needed. No "implementation-defined evaluation semantics." No UB in your safety checks. Just... types.

I know this gets said every thread but maybe the fact that it gets said every thread is trying to tell you something.

Let me list what is not in the MVP:

1. No contracts on virtual functions (removed at Hagenberg, vote: 20|24|13|14|2)
2. No contracts on function pointers
3. No contracts on coroutines
4. No assume semantic (consensus against at St. Louis, 0|0|3|18|11)
5. No ODR for contract-bearing entities
6. No contracts in the standard library itself

What's left: free functions, non-virtual member functions, and templates. Which is genuinely useful! But people expecting to slap pre() on their virtual interface hierarchies are going to have a bad time.

The phasing argument - ship the core, iterate on the extensions - is reasonable. The risk is that "iterate later" in WG21 means "revisit in 2031."

For those wondering "didn't we already have this?" - a comparison:

Boost.Contract - library-based, uses RAII tricks and macros, supports class invariants, old values, subcontracting (virtual function Liskov checks). Works today. Verbose. Significant compile-time cost. Nobody uses it.

GSL Expects()/Ensures() - macros. Configurable behavior (terminate, throw, nothing). Widely used in codebases that follow the Core Guidelines. Dead simple. No compiler integration.

assert() - the OG. Binary: on or off via NDEBUG. No postconditions. No customization. Everyone uses it.

P2900 contracts - language feature. Four evaluation semantics. Compiler sees the annotations. Part of the function declaration. Customizable violation handler. No class invariants yet. No old values yet. No subcontracting.

So P2900 is roughly "GSL Expects/Ensures but in the language, with more modes, and the compiler knows about it." The things Boost.Contract does that P2900 doesn't (invariants, subcontracting, old values) are explicitly deferred to future papers.

From the implementation side: LLVM #127870 tracks the Clang P2900 work. GCC has experimental patches. The core feature is straightforward to lower - preconditions become checks at function entry, postconditions at exit, with a call to the violation handler on failure.

The interesting codegen question is what happens with quick_enforce. In theory, the compiler terminates immediately without calling the handler, which means it can be lowered to something like a conditional trap instruction on architectures that have one (ARM brk, x86 ud2). Zero function-call overhead. That's the "we measured this at Bloomberg and the overhead was acceptable in production" story.

The complicated part is observe - the handler runs, and then execution continues. The compiler has to emit a call, handle potential exceptions from the handler, and then keep going as if nothing happened. This has real implications for optimization - the compiler can't assume the precondition is true after an observe-mode check.

Something that's going to surprise people. In P2900, postcondition predicates see *this as const:

class widget {
    std::vector<int> data_;
public:
    void sort()
        post(std::is_sorted(data_.begin(),
                            data_.end()))
    {
        std::sort(data_.begin(), data_.end());
    }
};

This compiles because begin() and end() have const overloads. But:

    void process()
        post(this->is_valid())
    {
        // ...
    }

If is_valid() is not const-qualified, this is ill-formed. The Hagenberg vote on removing constification was 9|7|6|37|14 - overwhelmingly against removing it. The rationale: predicates should be side-effect-free.

Reasonable. But it means you need const-correct APIs to use postconditions effectively. Which is... not the state of most C++ codebases I've worked in.

The violation handler story is more complex than most people realize. The handler can throw. This was explicitly preserved - St. Louis voted 0|5|4|9|16 against banning exceptions from the handler.

So consider: you have a noexcept function with a precondition. The precondition fails. The handler throws. Now what? You're throwing out of a noexcept function. That's std::terminate. Which is maybe what you wanted, but it means the handler's "recovery" path is silently killed.

The interaction matrix between evaluation semantics, noexcept, and handler behavior is something I expect to generate a lot of Stack Overflow questions in 2027.

Let me make sure I understand this correctly. P2900 lets me write:

int safe_divide(int a, int b)
    pre(b != 0)
{
    return a / b;
}

And then the compiler is allowed to... not check it. At all. The pre(b != 0) is in the source. The compiler sees it. And it goes "nah." Because the evaluation semantic is ignore.

I understand why. Performance. Same argument as NDEBUG for assert. Fine. But assert is a macro - it's obviously conditional, you can see #ifdef NDEBUG in the header. With P2900, the syntax looks unconditional. You wrote a precondition. It looks like it's part of the function's interface. A new team member reads that code and thinks the division is protected.

The selection of a contract evaluation semantic for a given contract assertion is implementation-defined.

That sentence is doing a LOT of work.

quick_enforce is the semantic that justifies this entire paper for us. We run contract checks in production. Not debug builds, production. On the hot path. When we detect a violated precondition, we want the process dead immediately - no handler, no stack unwinding, no logging. Just trap. Reboot. Failover handles it.

Our current mechanism is a custom FATAL_CHECK macro that compiles to __builtin_trap(). It works but the compiler doesn't know it's a precondition, so it can't optimize around it. With quick_enforce, the compiler knows the predicate is expected to be true, and if it's false, the process is gone. That's exactly our model.

The thing that doesn't get enough discussion: should this have been a TS?

P3265R3 argued for a Contracts TS. The SG21 chairs responded with P3269R0 arguing against. The committee sided with shipping in the IS.

The TS argument: implementation experience is thin. Only experimental compiler branches exist. No production deployments at scale. The C++20 contracts failure should have taught us that shipping early leads to pulling features.

The IS argument: a TS delays adoption by 3-6 years. The design has been iterated for five years in SG21 with more committee review than most features. A TS for contracts would have been the first TS for a language feature since Concepts TS, and the Concepts TS showed that TS-based design exploration creates more churn, not less.

Real question: how are evaluation semantics going to work in practice? Is this a compiler flag? Per-TU? Per-function? Does my CMakeLists.txt need a target_contract_semantics()? Does -fcontracts=enforce apply to everything including third-party headers?

Because I can already see the bug report: "my release build crashes because some library was compiled with quick_enforce and my code passes bad inputs that were fine when the library was compiled with ignore."

real talk: what's the compile time impact? every contract annotation is an additional expression the compiler has to parse, type-check, and potentially instantiate (in templates). Our codebase has ~40k source files. If contracts add even 2% to compile times I'm going to hear about it from management.

For the new people: C++ has tried to standardize contracts before. P0542R5 was voted into the C++20 working draft at Rapperswil in 2018. Then the design started unraveling - disagreements over assume semantics, checking levels, interaction with optimization. By Cologne 2019 the design was so contested that it was pulled entirely from C++20.

SG21 was formed specifically to fix this. Five years of design iteration later, P2900 is a fundamentally different paper with different authors, different semantics, and different design philosophy. The only thing it shares with the C++20 attempt is the word "contracts."

Whether the committee learned the right lessons from 2019 depends on who you ask. The 12 SA voters would say no. The 42 in favor would say yes. We'll know for sure in about three years when implementations mature.

Has anyone read P3506R0? "P2900 Is Still Not Ready for C++26." The list of concerns is not crankery - it's from people who implement compilers:

UB in predicates, unresolved virtual function semantics, deferred function-pointer story, exception-to-false mapping, constification, and thin standard library "experience."

And P3573R0 raised similar concerns. These aren't fringe positions. These are the people who have to make this work.

Eiffel had this in 1986. Design by Contract with full class invariants, old-value capture, and Liskov-compliant subcontracting. Thirty-nine years later, C++ gets preconditions and postconditions without invariants, without old values, and without subcontracting. The "MVP" is a feature that was complete in another language before most of this subreddit was born.

I'm glad it's happening. I'm just... not going to pretend it's groundbreaking.

Master C++26 Contracts in just 30 days! Our exclusive course covers everything from pre/post to violation handlers. Use code REDDIT20 for 20% off. Link in bio.

The elephant in the room is the safety narrative. The White House told everyone to stop using memory-unsafe languages. The NSA published guidance. Google and Microsoft publish annual CVE counts showing C++ memory bugs. And the committee's response for C++26 is... a feature that lets you write pre(ptr != nullptr) and then the compiler might not check it, and if it does check it and the pointer is dangling, the check itself is UB.

I'm a contracts supporter. I think this is net positive. But let's not pretend this is the answer to the safety question. P3500R1 ("Are Contracts Safe?") asked exactly this and the answer is: contracts are orthogonal to memory safety. They don't prevent use-after-free. They don't prevent buffer overflows. They catch logic errors in the domain layer, which is valuable but different.

If someone tries to market C++26 contracts as "C++ is now safe," push back.

FWIW, Bloomberg has been using contract-like annotations internally for years. Their internal BSLS_ASSERT facility is essentially what P2900 standardizes, minus the postconditions. They have data on the overhead, the debugging value, and the false-positive rate across millions of lines of production code. This isn't a theoretical proposal - it's a standardization of established practice from multiple organizations.

The authors know what they're doing. Joshua Berne is Bloomberg. The design reflects production experience. Whether the committee added the right amount of generality on top of that experience is the question.

scrolled through 87 comments expecting a consensus on whether this is good or bad. got sarcasm, a Rust tangent, a deleted conspiracy theory, two compiler devs disagreeing about trap instructions, and a spam bot. classic r/wg21.

anyway I'm cautiously optimistic. it's not perfect but it's something. better than writing assert(false && "unreachable") for another decade.