Balloting has completed for C++26. Unfortunately it was Disapproved

I would be very interested to watch those talks on why contracts are bad. Do you remember a name, the speaker, the conference or anything else which could be used to find them?

It’s hard to write a good critique of contracts because the spec is incredibly complex, most of it is implementation defined, and whenever you criticise one bit the advocates tell you that this is an implementation-defined choice and implementations can do the other thing. Then, in the next conversation they say the same thing but about something where both choices cannot exist in the same implementation (and then we’re told that people aren’t acting in good faith when criticising contracts, which is when I give up on the process).

This is really my biggest complaint about it. It isn’t a spec, it’s an enumeration of a large space of possible features, many of which are mutually incompatible.

This leads onto the next issue. For safety and security, the most important thing is source-level and local reasoning. If someone needs to sign off on some component meeting some requirements, the less of the global system they need to understand, the better. For contracts, the semantics may change based on implementation-defined external behaviour. They may differ depending on how some other compilation unit in the system was compiled. They may change based on later static and dynamic linker options (note: the C++ standard still pretends dynamic linking isn’t a thing, which it should really get over).

It also comes with non-composable abstractions. There is a global handler for contract violation handlers. I thought we learned from std::set_unexpected that this was a terrible idea. There is a promise from the contracts people that this will be changed in the future but no word on how that will be done in a way that avoids breaking code that deployed contracts and has then built the assumption that their handler has global visibility of failures into their assurance model for auditing, for example.

There are a bunch of related issues like this. Every modern assertions framework provides mechanisms for fine-grained control. The one in CHERIoT RTOS, for example, which is intentionally simple because it runs on embedded systems, lets you turn on and off both the verbosity of reporting and whether the checks occur at a per-subsystem granularity (which may be multiple toggles in a single file). It also has a notion of checks that will always happen but will trap on failure if the verbosity is turned off, versus ones where the check is skipped. Adding that requires a load of new syntax in places where contracts have already define syntax.

And defining new syntax at this stage is problematic. Contracts define new syntax and new semantics. There’s no effort made to ensure that the new semantics are reusable. For example, contracts introduce a notion that you can have two versions of a function that have different run-time behaviours. This is defined to not be an ODR violation, but its implementation defined what actually happens. This is a thing that would be generally useful (and would actually make C assert work in C++ headers) if the semantics were properly specified, but they weren’t. Similarly, pre- and post-conditions provide a mechanism for defining code that runs before or after a function. Python calls these decorators and they’re a very flexible and generic mechanism. Contracts define a specific kind of decorator with tightly coupled semantics.

We have no real data to support the idea that this syntax is the right one. For example, if I’m designing a clean and regular API then I probably want to apply the same contracts in a bunch of places. We already have compiler support for a bunch of ad-hoc contracts such as non-null, but these can’t use the contracts mechanism because they’re parameter attributes not function preconditions. By defining the pre- and post-condition syntax tightly coupled with the semantics, we don’t get to explore that design space. If we’d started with a permitted way of doing ODR violation and a way of writing function decorators, we could have had a standard-library (or other library!) implementation of contracts, seen how people use, it and then added special-case syntax for the most common operations. Instead, jumping to syntax with implementation-defined semantics means that we can’t do any of that.

There were claims made during the process that Microsoft had found contracts in C++ made their static analysis tooling faster. Except Microsoft never actually implemented contracts internally and the design allows contracts to call functions defined in other compilation units (and even other libraries) so this is not only incorrect with respect to what did happen, it’s also misleading about what could happen, unless you constrain your use of contracts to a tool-defined subset.

The static analysis side is quite sad. Verus in Rust uses pre- and post-conditions and is amazing. It uses a restricted subset of the language, adds the ability to carry ghost state, and lets you formally verify properties that go way beyond the Rust type system. This is explicitly out of scope for C++ contracts. They allow arbitrary C++, including calls to extern symbols, so can’t be used with a proof engine unless you explicitly define your own subset (at which point, anyone else writing contracts in a component that you use can break your code).

Which leads onto a core issue: what are contracts for? If they’re not for formal verification (where they are phenomenally useful and let you decompose proofs into tractable local properties that you can build on up and down the call stack), they’re Eiffel-style dynamic checks. And that’s a ‘90s programming style that I hoped we’d moved away from. The ‘parse don’t verify’ and ‘make invalid states unrepresentable’ shift was great for quality. C++ leaned into this: types define invariants, you check them at construction time and can then assume them through the instance’s lifetime. Building that model as the core of the system is, to my mind, the main reason that Rust code is more likely to be correct than C code. C++ is in the middle and was slowly shifting to the Rust end. Contracts are a step back.

We should be making it easier to do things like have wrapper types that are guaranteed to have the same representation as the wrapped type, for example, and allowing consteval ghost state so type-level invariants can be passed around more easily. The contracts effort had sucked all of the air out of the room for approaches that actually solve the problems that contracts claim to address.

TL;DR: P2900 Contracts are a bad solution to the wrong problem.

and the fact that you appear to believe that these complaints had not been considered

@refi64 never said this. They literally link to a paper which says "WG21 has carefully considered each individual concern, weighed the trade-offs involved, and ultimately decided, in each case, in favour of the specification that is now in the C++26 DIS".

P4334 is useful for people like me who are out of the loop and want to understand where the disagreements lie with contracts. Clearly there's still no consensus, and plenty of people are very unhappy with contracts in their current state, and so it's nice to have some context on why that is. Just linking to a paper (alongside other papers showing the opposite side's stance!) doesn't imply that it hasn't been "heard and considered" by the committee.