C++26 is introducing a contracts facility designed to make assumptions about program behavior visible in function interfaces rather than leaving them buried in implementation code. The feature provides syntax for preconditions, postconditions and assertions within a function, giving developers a standard vocabulary for describing what callers must supply and what a function promises on normal return.
A precondition written with `pre(...)` follows a function's parameter list. Unlike a conventional `assert` inside the body, it can appear on the first declaration, including in a header, where someone reading the API can see it without opening the implementation. A later declaration or definition may repeat the same contract sequence or omit it, but cannot introduce a different one. Contracts are associated with functions without becoming part of their types, so overload resolution does not distinguish otherwise identical functions by their contract conditions.
Postconditions use `post(...)` and can name the returned value, allowing one condition to cover every normal return path. They do not test exits caused by exceptions. C++26 also includes `contract_assert` for conditions checked at a particular point inside a function, such as a relationship between counters during an algorithm. Together, the three forms cover entry, normal completion and internal state.
Runtime behavior depends on the evaluation policy chosen by the implementation. An ignored contract performs no runtime check. Under an observe policy, a violation is reported but execution can continue if the handler returns; that can still allow unsafe code to run. An enforce policy terminates after the violation handler returns. The language does not provide portable per-assertion syntax that forces one policy for each ordinary contract assertion.
The feature also comes with constraints intended to keep predicates dependable. Values receive special const treatment inside predicates, and developers are advised not to put state-changing work there because evaluation may be disabled. Contracts are therefore not a replacement for ordinary validation of expected failures such as bad configuration input, which still needs normal control flow and user-facing error handling.
As of the event date, GCC 16 was the only compiler identified as supporting the C++26 facility, using dedicated compiler options. GCC can also allow a custom violation handler that receives details including the failed expression, source location and evaluation semantic. The result is a significant new mechanism for API documentation and diagnostics, but its safety effect still depends on compiler support and the selected runtime policy.
