{"article":{"slug":"c-26-contracts-introduction-to-preconditions-and-postconditions","title":"C++26 Contracts: Introduction to Preconditions and Postconditions","subtitle":null,"summary":"C++ Stories introduces C++26 contracts: pre() and post() on function declarations and contract_assert() inside functions, why they beat assert, the ignore/observe/enforce/quick-enforce evaluation semantics, compiling examples with GCC, const parameters in postconditions, avoiding side effects in predicates, predicate cost, and why contracts are not a replacement for input validation.","content_type":"tutorial","language":"en","canonical_url":"https://www.cppstories.com/2026/cpp26_contracts/","author":{"name":"Bartlomiej Filipek","url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"C++ Stories","url":"https://www.cppstories.com/","listing_slug":null,"listing":null},"topics":[{"name":"C++","slug":"c","url":"https://listedarticles.com/topics/c"},{"name":"Programming Languages","slug":"programming-languages","url":"https://listedarticles.com/topics/programming-languages"},{"name":"Software Safety","slug":"software-safety","url":"https://listedarticles.com/topics/software-safety"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":2052,"reading_minutes":9,"published_at":"2026-10-11T00:00:00.000Z","added_at":"2026-10-15T14:18:54.113Z","updated_at":"2026-10-15T14:18:54.113Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/c-26-contracts-introduction-to-preconditions-and-postconditions","markdown_url":"https://listedarticles.com/articles/c-26-contracts-introduction-to-preconditions-and-postconditions.md","example":false,"citation":"Bartlomiej Filipek, C++ Stories. \"C++26 Contracts: Introduction to Preconditions and Postconditions.\" 11 Oct 2026. https://www.cppstories.com/2026/cpp26_contracts/ (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://www.cppstories.com/2026/cpp26_contracts/"},"body_markdown":"In the article about [Standard Library hardening](https://www.cppstories.com/2026/hardening-experiments/), we looked at checks for invalid Standard Library container access and other broken preconditions. I mentioned that those requirements are expressed in terms of “contracts”. But what about our code?\n\nIn this post, we’ll explore contracts from C++26. We’ll start with a simple `cassert`, move the requirement into the function itself, and see how to check results. We’ll also look at declarations and definitions, compiler options, and a few details that can surprise you.\n\n## Starting with an Assertion\n\nLet’s start with a small example:\n\nA header file first:\n\n```\n// foo.h\n#include \nint get_value(const std::vector& values, std::size_t index);\n```\n\nAnd the implementation:\n\n```\n// foo.cpp\n#include \"foo.h\" // our function declaration...\n#include \n\nint get_value(const std::vector& values, std::size_t index) {\n assert(index < values.size());\n return values[index];\n}\n```\n\nThe function expects a valid index. If the condition is false, `assert` prints a diagnostic message and terminates the program. However, this only happens when assertions are enabled. Defining `NDEBUG` disables the check and basically removes the check from the code.\n\nWhat are the issues with this simple approach? The requirement lives inside the implementation. Somebody reading only the declaration sees a vector and an index, without the relationship between them.\n\n## Adding a Precondition\n\nWith C++26 contracts, we can move that requirement from an assertion inside the function body to the function itself:\n\n```\nint get_value(const std::vector& values, std::size_t index)\n pre(index < values.size())\n{\n return values[index];\n}\n```\n\nNotice the new `pre(...)` syntax after the parameter list. It introduces a *precondition assertion*: a condition expected to hold when entering the function.\n\nWhat’s more, we can add this precondition to the declaration:\n\n```\nint get_value(const std::vector& values, std::size_t index)\n pre(index < values.size());\n```\n\nThe feature was introduced through [P2900, Contracts for C++](https://wg21.link//p2900).\n\nLet’s understand how it works and how it differs from `assert`.\n\n### Why Use Contracts Instead of `assert`?\n\nAt first, `pre(index < values.size())` might look like another way to write `assert(index < values.size())`. Both express a condition that should be true. So what’s the benefit of using contracts?\n\nThere are a few important differences:\n\n- Requirements in declarations: We can put `pre` and `post` directly in the function declaration. This makes the requirements visible to anyone reading the API, without looking at the implementation.\n- More flexible checking: Traditional `assert` is enabled or disabled through `NDEBUG`. Contracts define several evaluation semantics, including ignoring a check, reporting a violation and continuing, or terminating the program. The compiler implementation determines which semantics are available and how they can be selected.\n- Preconditions and postconditions: Contracts distinguish between what the caller must provide and what the function promises to return. With `assert`, we would have to place checks manually inside the function body, including checks before different return statements.\n\nThis also makes contracts useful for documenting APIs, even when runtime checking is disabled.\n\n## A Complete Precondition Example\n\nHere’s a complete example (no header file for simplicity for now):\n\n```\n#include \n#include \n\nint get_value(const std::vector& values, std::size_t index)\n pre(index < values.size())\n{\n return values[index];\n}\n\nint main() {\n std::vector values { 10, 20, 30 };\n\n std::println(\"{}\", get_value(values, 1));\n // get_value(values, 10); // violates the precondition\n}\n```\n\nThe valid call prints:\n\n```\n20\n```\n\nAnd here’s the version for you to play with the problematic call uncommented:\n\nSee at [Compiler Explorer](https://godbolt.org/z/v9c4hr4va)\n\nOn GCC, I’m getting:\n\n```\nProgram returned: 134\nProgram stdout\n20\nProgram stderr\ncontract violation in function int get_value(const std::vector&, std::size_t) at /app/example.cpp:6: index < values.size()\n[assertion_kind: pre, semantic: enforce, mode: predicate_false, terminating: yes]\nterminate called without an active exception\nProgram terminated with signal SIGABRT (6)\n```\n\n## Contracts on Declarations and Definitions\n\nFor clarity, contracts can appear on a declaration, in a definition, or both:\n\n```\nint get_value(const std::vector& values, std::size_t index)\n pre(index < values.size());\n```\n\nThe definition can then omit the contract specifier:\n\n```\nint get_value(const std::vector& values, std::size_t index)\n{\n return values[index];\n}\n```\n\nThe contract assertions are established by the function’s first declaration. A later declaration or definition may omit the contract specifiers, as above, or repeat the same sequence.\n\nA later declaration cannot introduce a different set of preconditions or postconditions.\n\nIn practice, if a function is declared in a header, that first declaration is the natural place for its preconditions and postconditions. If you’re reading the API, it’s probably best to see all preconditions without looking inside the implementation.\n\nWhat’s more, contracts are associated with the function, but they are not part of the function type. Overload resolution, for example, does not distinguish functions based on their contracts.\n\n## Contract Evaluation Semantics\n\nC++26 defines four evaluation semantics:\n\n| Semantic | What happens at runtime? |\n| --- | --- |\n| Ignore | The predicate is not evaluated. |\n| Observe | A violation invokes the handler; execution continues if it returns normally. |\n| Enforce | A violation invokes the handler; execution terminates if it returns normally. |\n| Quick-enforce | A violation terminates execution without invoking the handler. |\n\nThe implementation determines which semantic applies. C++26 has no portable syntax for forcing an individual ordinary contract assertion to use one specific policy. These rules appear in the [contract evaluation specification](https://eel.is/c++draft/basic.contract.eval).\n\nWith the ignore semantic, no runtime check is performed. With observe, a violation is reported, but execution continues if the handler returns normally. In our example, both policies can allow the program to reach `values[index]` with an invalid index, resulting in undefined behavior.\n\nThus, adding `pre(...)` expresses the requirement, while the selected policy determines how checking responds.\n\n## Compiling with GCC\n\nAs of October 2026, only GCC 16 supports Contracts. We can use it with special compile flags:\n\n```\ng++ -std=c++26 -fcontracts \\\n -fcontract-evaluation-semantic=enforce example.cpp\n```\n\nWith that policy, the invalid call invokes the violation handler. If the handler returns normally, execution terminates before the function body performs the invalid access. GCC’s default handler emits diagnostic information. See the [GCC options documentation - contracts](https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-fcontracts).\n\nGCC also allows us to replace the default contract-violation handler. For example, we can log a custom message when a violation is detected.\n\nThe handler receives a `std::contracts::contract_violation` object, which provides information about the failed contract, including the predicate, location, and evaluation semantic.\n\n```\n#include \n#include \n\nvoid handle_contract_violation(\n const std::contracts::contract_violation& violation)\n{\n std::println(stderr, \"Contract violated: {}\",\n violation.comment());\n}\n```\n\nSee an example [@Compiler Explorer](https://godbolt.org/z/YT941W6vx)\n\nNotice that replacing the handler doesn’t change what happens after it returns. With `observe`, execution continues. With `enforce`, the program terminates.\n\nNot every implementation is required to support replacing the handler, so this feature is implementation-defined.\n\n## Adding a Postcondition\n\nSo far, we’ve described what the caller must provide. We can also describe what a function promises when it returns normally.\n\nSee this example:\n\n```\nint clamp_value(int value, const int low, const int high)\n pre(low <= high)\n post(result: result >= low && result <= high)\n{\n if (value < low)\n return low;\n if (value > high)\n return high;\n return value;\n}\n```\n\nThere are two useful pieces here:\n\n- `pre(low <= high)` checks that the bounds form a valid interval.\n- `post(result: ...)` checks that the returned value lies inside that interval.\n\nThe name `result` is ours to choose. It refers to the function’s result within that postcondition.\n\nWhat’s convenient is that the same postcondition covers every normal return path. We don’t have to repeat an assertion before each `return`.\n\nHere’s an example where I deliberately violated the postcondition:\n\n```\n#include \n\nint clamp_value(int value, const int low, const int high)\n pre(low <= high)\n post(result: result >= low && result <= high)\n{\n if (value < low)\n return low-10; // <<\n if (value > high)\n return high;\n return value;\n}\n\nint main() {\n std::print(\"{}\", clamp_value(10, 20, 30));\n}\n```\n\nSee [@Compiler Explorer](https://godbolt.org/z/c9asf75M5)\n\nAnd on GCC I’m getting:\n\n```\ncontract violation in function int clamp_value(int, int, int) at /app/example.cpp:5: result >= low && result <= high\n[assertion_kind: post, semantic: enforce, mode: predicate_false, terminating: yes]\nterminate called without an active exception\nProgram terminated with signal SIGABRT (6)\n```\n\nThe precondition is fine, but the postcondition is broken.\n\n### Const Parameters in Postconditions\n\nThere’s also a detail in the parameter list: `low` and `high` are `const`.\n\nYou will get the following error if you try making them non-const:\n\n```\nsource>:5:28: error: a value parameter used in a postcondition must be const\n 5 | post(result: result >= low && result <= high)\n```\n\nWhen a postcondition uses a parameter passed by value, that parameter must have `const` type on every declaration. Our comparisons use both bounds this way. The parameter `value` is only used in the body, so this requirement doesn’t apply to it.\n\nPostconditions apply to normal exit; they do not check the result when the function body exits through an exception. See the [function contract rules](https://eel.is/c++draft/dcl.contract).\n\n## Assertions Inside a Function\n\nFor conditions inside an implementation, we have `contract_assert`:\n\n```\n#include \n\nstd::size_t count_spaces(std::string_view text) {\n std::size_t count = 0;\n\n for (char ch : text) {\n if (ch == ' ')\n ++count;\n }\n\n contract_assert(count <= text.size());\n return count;\n}\n```\n\nThe condition is simple, but it expresses a useful property: the number of spaces cannot exceed the number of characters.\n\nIn a larger algorithm, such a check could describe a relationship between counters, an intermediate result, or the state after processing a block of data.\n\nTogether, `pre`, `post`, and `contract_assert` cover function entry, normal exit, and points inside a function.\n\n## Avoiding Mutation in Predicates\n\nOne thing to watch during migration is mutation inside predicates:\n\n```\nvoid process(int count)\n pre(++count > 0) // error\n{\n}\n```\n\nSee [@Compiler Explorer](https://godbolt.org/z/9j4TMbfzn)\n\nAn error from GCC:\n\n```\nerror: increment of read-only location '(const int)count'\n 2 | pre(++count > 0) // error\n```\n\nContract predicates use special constification rules. In this example, count is treated as const inside the predicate, so `++count` is rejected by the compiler.\n\nHowever, this does not make predicates completely free of side effects. For example, a predicate can still call a function that modifies global state. Since contract evaluation may be ignored, and side effects are not guaranteed even under checking semantics, predicates should not modify program state.\n\n## Contracts Are Not Input Validation\n\nThere’s another practical distinction: input validation.\n\nSuppose an index comes from a configuration file. If an invalid value requires an error message, that handling belongs in ordinary control flow:\n\n```\nif (index >= values.size()) {\n std::println(\"Invalid index: {}\", index);\n return;\n}\n\nstd::println(\"{}\", get_value(values, index));\n```\n\nThe validation handles an expected failure at the application boundary. The precondition documents the internal helper’s requirements.\n\nP2900 explicitly discusses this idea in:\n\n> Principle 12: Contract Assertions Are Not Flow Control:\n> While a contract assertion provides an algorithm to validate correctness, nothing about a contract assertion guarantees any particular runtime behavior associated with that syntactic construct.\n\nAnd more:\n\n> 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.\n\n## Considering Predicate Costs\n\nFinally, one note about performance implications.\n\nOur index comparison is cheap. A condition that verifies whether an entire collection is sorted needs to examine its elements. An expensive check may be useful during testing, but you should measure its effect on representative workloads.\n\n## Summary\n\nC++26 contracts give us three ways to express assumptions and guarantees directly in the language:\n\n- `pre(...)` describes conditions expected to hold when a function is entered,\n- `post(...)` describes conditions expected to hold when a function returns normally,\n- `contract_assert(...)` checks properties at specific points inside a function.\n\nPreconditions and postconditions are associated with the function through its declarations. In particular, the first declaration establishes the contract, which makes declarations in header files a natural place to document an API’s requirements.\n\nA contract assertion does not necessarily mean that a runtime check will always be performed. The selected evaluation semantic can ignore, observe, enforce, or quick-enforce the assertion. Code therefore shouldn’t depend on contract predicates for required application logic or side effects.\n\nContracts also aren’t a replacement for normal input validation. Use regular control flow for errors that your program expects and needs to handle.\n\n## References\n\n- [P2900, Contracts for C++](https://wg21.link//p2900)\n- [Contract assertions (since C++26) - cppreference.com - C++ Reference](https://cppreference.dev/w/cpp/language/contracts)\n- [How C++26 Contracts Improve Correctness Without Sacrificing Performance | Citadel Securities](https://www.citadelsecurities.com/careers/career-perspectives/how-cpp26-contracts-improve-correctness-without-sacrificing-performance/)\n- [How C++26 contracts work | Train IT](https://train-it.eu/blog/how-cpp26-contracts-work/)\n- [Test Driving C++26 Contracts with GCC 16.1 | Fabian Koehler](https://fkoehler.me/posts/2026/05/test-driving-cpp26-contracts-with-gcc-16-1/)\n","body_html":"

In the article about Standard Library hardening, we looked at checks for invalid Standard Library container access and other broken preconditions. I mentioned that those requirements are expressed in terms of “contracts”. But what about our code?

\n

In this post, we’ll explore contracts from C++26. We’ll start with a simple cassert, move the requirement into the function itself, and see how to check results. We’ll also look at declarations and definitions, compiler options, and a few details that can surprise you.

\n

Starting with an Assertion

\n

Let’s start with a small example:

\n

A header file first:

\n
// foo.h\n#include <vector>\nint get_value(const std::vector<int>& values, std::size_t index);
\n

And the implementation:

\n
// foo.cpp\n#include "foo.h" // our function declaration...\n#include <cassert>\n\nint get_value(const std::vector<int>& values, std::size_t index) {\n    assert(index < values.size());\n    return values[index];\n}
\n

The function expects a valid index. If the condition is false, assert prints a diagnostic message and terminates the program. However, this only happens when assertions are enabled. Defining NDEBUG disables the check and basically removes the check from the code.

\n

What are the issues with this simple approach? The requirement lives inside the implementation. Somebody reading only the declaration sees a vector and an index, without the relationship between them.

\n

Adding a Precondition

\n

With C++26 contracts, we can move that requirement from an assertion inside the function body to the function itself:

\n
int get_value(const std::vector<int>& values, std::size_t index)\n    pre(index < values.size())\n{\n    return values[index];\n}
\n

Notice the new pre(...) syntax after the parameter list. It introduces a precondition assertion: a condition expected to hold when entering the function.

\n

What’s more, we can add this precondition to the declaration:

\n
int get_value(const std::vector<int>& values, std::size_t index)\n    pre(index < values.size());
\n

The feature was introduced through P2900, Contracts for C++.

\n

Let’s understand how it works and how it differs from assert.

\n

Why Use Contracts Instead of assert?

\n

At first, pre(index < values.size()) might look like another way to write assert(index < values.size()). Both express a condition that should be true. So what’s the benefit of using contracts?

\n

There are a few important differences:

\n
  • Requirements in declarations: We can put pre and post directly in the function declaration. This makes the requirements visible to anyone reading the API, without looking at the implementation.
  • More flexible checking: Traditional assert is enabled or disabled through NDEBUG. Contracts define several evaluation semantics, including ignoring a check, reporting a violation and continuing, or terminating the program. The compiler implementation determines which semantics are available and how they can be selected.
  • Preconditions and postconditions: Contracts distinguish between what the caller must provide and what the function promises to return. With assert, we would have to place checks manually inside the function body, including checks before different return statements.
\n

This also makes contracts useful for documenting APIs, even when runtime checking is disabled.

\n

A Complete Precondition Example

\n

Here’s a complete example (no header file for simplicity for now):

\n
#include <print>\n#include <vector>\n\nint get_value(const std::vector<int>& values, std::size_t index)\n    pre(index < values.size())\n{\n    return values[index];\n}\n\nint main() {\n    std::vector<int> values { 10, 20, 30 };\n\n    std::println("{}", get_value(values, 1));\n    // get_value(values, 10); // violates the precondition\n}
\n

The valid call prints:

\n
20
\n

And here’s the version for you to play with the problematic call uncommented:

\n

See at Compiler Explorer

\n

On GCC, I’m getting:

\n
Program returned: 134\nProgram stdout\n20\nProgram stderr\ncontract violation in function int get_value(const std::vector<int>&, std::size_t) at /app/example.cpp:6: index < values.size()\n[assertion_kind: pre, semantic: enforce, mode: predicate_false, terminating: yes]\nterminate called without an active exception\nProgram terminated with signal SIGABRT (6)
\n

Contracts on Declarations and Definitions

\n

For clarity, contracts can appear on a declaration, in a definition, or both:

\n
int get_value(const std::vector<int>& values, std::size_t index)\n    pre(index < values.size());
\n

The definition can then omit the contract specifier:

\n
int get_value(const std::vector<int>& values, std::size_t index)\n{\n    return values[index];\n}
\n

The contract assertions are established by the function’s first declaration. A later declaration or definition may omit the contract specifiers, as above, or repeat the same sequence.

\n

A later declaration cannot introduce a different set of preconditions or postconditions.

\n

In practice, if a function is declared in a header, that first declaration is the natural place for its preconditions and postconditions. If you’re reading the API, it’s probably best to see all preconditions without looking inside the implementation.

\n

What’s more, contracts are associated with the function, but they are not part of the function type. Overload resolution, for example, does not distinguish functions based on their contracts.

\n

Contract Evaluation Semantics

\n

C++26 defines four evaluation semantics:

\n
SemanticWhat happens at runtime?
IgnoreThe predicate is not evaluated.
ObserveA violation invokes the handler; execution continues if it returns normally.
EnforceA violation invokes the handler; execution terminates if it returns normally.
Quick-enforceA violation terminates execution without invoking the handler.
\n

The implementation determines which semantic applies. C++26 has no portable syntax for forcing an individual ordinary contract assertion to use one specific policy. These rules appear in the contract evaluation specification.

\n

With the ignore semantic, no runtime check is performed. With observe, a violation is reported, but execution continues if the handler returns normally. In our example, both policies can allow the program to reach values[index] with an invalid index, resulting in undefined behavior.

\n

Thus, adding pre(...) expresses the requirement, while the selected policy determines how checking responds.

\n

Compiling with GCC

\n

As of October 2026, only GCC 16 supports Contracts. We can use it with special compile flags:

\n
g++ -std=c++26 -fcontracts \\\n    -fcontract-evaluation-semantic=enforce example.cpp
\n

With that policy, the invalid call invokes the violation handler. If the handler returns normally, execution terminates before the function body performs the invalid access. GCC’s default handler emits diagnostic information. See the GCC options documentation - contracts.

\n

GCC also allows us to replace the default contract-violation handler. For example, we can log a custom message when a violation is detected.

\n

The handler receives a std::contracts::contract_violation object, which provides information about the failed contract, including the predicate, location, and evaluation semantic.

\n
#include <contracts>\n#include <print>\n\nvoid handle_contract_violation(\n    const std::contracts::contract_violation& violation)\n{\n    std::println(stderr, "Contract violated: {}",\n                 violation.comment());\n}
\n

See an example @Compiler Explorer

\n

Notice that replacing the handler doesn’t change what happens after it returns. With observe, execution continues. With enforce, the program terminates.

\n

Not every implementation is required to support replacing the handler, so this feature is implementation-defined.

\n

Adding a Postcondition

\n

So far, we’ve described what the caller must provide. We can also describe what a function promises when it returns normally.

\n

See this example:

\n
int clamp_value(int value, const int low, const int high)\n    pre(low <= high)\n    post(result: result >= low && result <= high)\n{\n    if (value < low)\n        return low;\n    if (value > high)\n        return high;\n    return value;\n}
\n

There are two useful pieces here:

\n
  • pre(low <= high) checks that the bounds form a valid interval.
  • post(result: ...) checks that the returned value lies inside that interval.
\n

The name result is ours to choose. It refers to the function’s result within that postcondition.

\n

What’s convenient is that the same postcondition covers every normal return path. We don’t have to repeat an assertion before each return.

\n

Here’s an example where I deliberately violated the postcondition:

\n
#include <print>\n\nint clamp_value(int value, const int low, const int high)\n    pre(low <= high)\n    post(result: result >= low && result <= high)\n{\n    if (value < low)\n        return low-10; // <<\n    if (value > high)\n        return high;\n    return value;\n}\n\nint main() {\n    std::print("{}", clamp_value(10, 20, 30));\n}
\n

See @Compiler Explorer

\n

And on GCC I’m getting:

\n
contract violation in function int clamp_value(int, int, int) at /app/example.cpp:5: result >= low && result <= high\n[assertion_kind: post, semantic: enforce, mode: predicate_false, terminating: yes]\nterminate called without an active exception\nProgram terminated with signal SIGABRT (6)
\n

The precondition is fine, but the postcondition is broken.

\n

Const Parameters in Postconditions

\n

There’s also a detail in the parameter list: low and high are const.

\n

You will get the following error if you try making them non-const:

\n
source>:5:28: error: a value parameter used in a postcondition must be const\n    5 |     post(result: result >= low && result <= high)
\n

When a postcondition uses a parameter passed by value, that parameter must have const type on every declaration. Our comparisons use both bounds this way. The parameter value is only used in the body, so this requirement doesn’t apply to it.

\n

Postconditions apply to normal exit; they do not check the result when the function body exits through an exception. See the function contract rules.

\n

Assertions Inside a Function

\n

For conditions inside an implementation, we have contract_assert:

\n
#include <string_view>\n\nstd::size_t count_spaces(std::string_view text) {\n    std::size_t count = 0;\n\n    for (char ch : text) {\n        if (ch == ' ')\n            ++count;\n    }\n\n    contract_assert(count <= text.size());\n    return count;\n}
\n

The condition is simple, but it expresses a useful property: the number of spaces cannot exceed the number of characters.

\n

In a larger algorithm, such a check could describe a relationship between counters, an intermediate result, or the state after processing a block of data.

\n

Together, pre, post, and contract_assert cover function entry, normal exit, and points inside a function.

\n

Avoiding Mutation in Predicates

\n

One thing to watch during migration is mutation inside predicates:

\n
void process(int count)\n    pre(++count > 0) // error\n{\n}
\n

See @Compiler Explorer

\n

An error from GCC:

\n
error: increment of read-only location '(const int)count'\n    2 |     pre(++count > 0) // error
\n

Contract predicates use special constification rules. In this example, count is treated as const inside the predicate, so ++count is rejected by the compiler.

\n

However, this does not make predicates completely free of side effects. For example, a predicate can still call a function that modifies global state. Since contract evaluation may be ignored, and side effects are not guaranteed even under checking semantics, predicates should not modify program state.

\n

Contracts Are Not Input Validation

\n

There’s another practical distinction: input validation.

\n

Suppose an index comes from a configuration file. If an invalid value requires an error message, that handling belongs in ordinary control flow:

\n
if (index >= values.size()) {\n    std::println("Invalid index: {}", index);\n    return;\n}\n\nstd::println("{}", get_value(values, index));
\n

The validation handles an expected failure at the application boundary. The precondition documents the internal helper’s requirements.

\n

P2900 explicitly discusses this idea in:

\n

Principle 12: Contract Assertions Are Not Flow Control:\nWhile a contract assertion provides an algorithm to validate correctness, nothing about a contract assertion guarantees any particular runtime behavior associated with that syntactic construct.

\n

And more:

\n

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.

\n

Considering Predicate Costs

\n

Finally, one note about performance implications.

\n

Our index comparison is cheap. A condition that verifies whether an entire collection is sorted needs to examine its elements. An expensive check may be useful during testing, but you should measure its effect on representative workloads.

\n

Summary

\n

C++26 contracts give us three ways to express assumptions and guarantees directly in the language:

\n
  • pre(...) describes conditions expected to hold when a function is entered,
  • post(...) describes conditions expected to hold when a function returns normally,
  • contract_assert(...) checks properties at specific points inside a function.
\n

Preconditions and postconditions are associated with the function through its declarations. In particular, the first declaration establishes the contract, which makes declarations in header files a natural place to document an API’s requirements.

\n

A contract assertion does not necessarily mean that a runtime check will always be performed. The selected evaluation semantic can ignore, observe, enforce, or quick-enforce the assertion. Code therefore shouldn’t depend on contract predicates for required application logic or side effects.

\n

Contracts also aren’t a replacement for normal input validation. Use regular control flow for errors that your program expects and needs to handle.

\n

References

\n","headings":[{"level":2,"text":"Starting with an Assertion","id":"starting-with-an-assertion"},{"level":2,"text":"Adding a Precondition","id":"adding-a-precondition"},{"level":3,"text":"Why Use Contracts Instead of assert?","id":"why-use-contracts-instead-of-assert"},{"level":2,"text":"A Complete Precondition Example","id":"a-complete-precondition-example"},{"level":2,"text":"Contracts on Declarations and Definitions","id":"contracts-on-declarations-and-definitions"},{"level":2,"text":"Contract Evaluation Semantics","id":"contract-evaluation-semantics"},{"level":2,"text":"Compiling with GCC","id":"compiling-with-gcc"},{"level":2,"text":"Adding a Postcondition","id":"adding-a-postcondition"},{"level":3,"text":"Const Parameters in Postconditions","id":"const-parameters-in-postconditions"},{"level":2,"text":"Assertions Inside a Function","id":"assertions-inside-a-function"},{"level":2,"text":"Avoiding Mutation in Predicates","id":"avoiding-mutation-in-predicates"},{"level":2,"text":"Contracts Are Not Input Validation","id":"contracts-are-not-input-validation"},{"level":2,"text":"Considering Predicate Costs","id":"considering-predicate-costs"},{"level":2,"text":"Summary","id":"summary"},{"level":2,"text":"References","id":"references"}]}}