C++26 Contracts Move Assertions Into Function Signatures
C++26 Contracts: Introduction to Preconditions and Postconditions
C++26 contracts let you attach preconditions and postconditions directly to function declarations, making requirements visible in the API instead of buried in implementation. The article walks through replacing assert with pre and post, covers evaluation semantics like ignore, observe, enforce, and quick-enforce, and shows GCC 16 compilation flags. It also warns that contracts are not input validation and that predicates must avoid mutation.
Importantly, this aspect of Contracts is why contract assertions must not be used for error handling and input validation: If a function has in-contract requirements to report certain events as errors, that handling must be done with standard C++ control statements that are not optional, never with contract assertions.
- cogman10
I don't like it.
I'm all for signing up for a contract if it can turn a runtime error into a compile time error. However, this looks like it just makes more runtime errors. At that point, these seem no better than `assert` except for the fact that they promise to really assert (probably).
The article also points out a big problem which is "Importantly, this aspect of Contracts is why contract assertions must not be used for error handling and input validation: If a function has in-contract requirements to report certain events as errors, that handling must be done with standard C++ control statements that are not optional, never with contract assertions."
That sort of muddy definition of what contracts are supposed to be used for is almost certainly going to make a mess. It's not input validation, but parameter validation.. but not really validation but rather checks which error out, but it's not errors we are producing.
- WalterBright
I used to be a big fan of contracts, and even implemented it in the Zortech C++ compiler back in the 90's:
https://www.digitalmars.com/ctg/contract.html
I implemented it in D as well. But, it just turned out to not be very useful.
- ZuLuuuuuu
This reminds me the "Design by Contract" concept from Eiffel programming language:
https://en.wikipedia.org/wiki/Design_by_contract
https://www.eiffel.com/values/design-by-contract/introductio...
- Surac
What are they even good forbid we can’t validate the input with? A convenient way to write down parameter ranges. Nothing more
- gavinray
Random tidbit: I wrote a GCC compiler plugin years ago to add Contracts to C/C++ while waiting for this to make it into the standard
https://gavinray97.github.io/blog/adding-invariant-to-cpp-de...
The post turned out to be more useful for an intro to writing GCC plugins than anything, but at least I had fun
- tsukikage
The article makes no mention of optimisation use cases. In case anyone already knows off the top of their heads and before I start digging for the answer, is part of the intent here for these to inform the optimiser stages, perhaps similarly to what the if (!(some_condition)) { __builtin_unreachable(); } idiom can achieve?
- MetaverseClub
I wonder what are the use cases in their mind when designing this.
For runtime assertions and documentations, yeah, it would work but it works without contract arguably ok.
For formal verification, the design is way off.
- randyrand
Maybe just me, but huge complicated languages like C++ seem as unappealing as ever.
If I’m going to write code by hand, the requirement for a beautiful pleasant language is bigger than ever.