C++26 Contracts: Introduction to Preconditions and Postconditions (cppstories.com)

they are literally meant to be better asserts, that can be shown on a function declaration.

They are basically asserts that you can put in headers. Which is great because asserts are usually useless to IDEs because you only get the headers for libraries.

And with the 'observe' mode you can turn them on in production code right away and collect data without a failed assert terminating.

contracts are intended to document hoare logic. i.e. pre, post, invariant.

They can be compile time if the compiler can verify them statically (where they become a noop), runtime otherwise, or disabled entirely if you can't prove them statically but don't want the overhead cost.

Realistically contracts will gradually evolve towards static/compile time asserts as tooling improves.

And like the blog post states, contracts are explicitly not input validation. They are there to encode what you expect and what you don't internally in your code rather than just documenting those pre/post/invariant conditions in comments.

    pre(x >= 0)

    pre(y >= 0)

    return x + y;

The bit about contracts not being input valuation is no different than the case for assertions. It's basically saying that if assertions were inappropriate, so are contracts. So if you find that like blurry, the blurriness predates contracts.

That said, the distinction is generally pretty clear: an assertion failure (and therefore a contract failure) indicates a bug. It must never happen, and therefore it must always be OK to suppress the validation. If you see it fire, that's a bug report, and your code needs fixing. And if your contract to the caller is that you will enforce some constraint on them (as opposed to assuming they already took care of ensuring it), then you need the validation in your runtime code.

It’s a standard way to do pre and post conditions. Clojure pre and post conditions also behave this way. If you force these conditions into compile-time checks, well, then you are introducing a second type system with refinement types into the language. And type checking would take a long time. Imagine someone writes a precondition for a function where its integer argument x needs to satisfy collatz(x)==1; do you now expect the compiler to prove the collatz conjecture or verify it for all 64-bit integers every compilation?

My experience using pre and post conditions in Clojure makes me really like them. They are a small but meaningful improvement over plain old assertions. And yes being able to turn them off is a feature not a bug. Don’t expect them to be like LiquidHaskell.

I would phrase the difference between contracts and input validation like this:

- If it can happen, but shouldn't, that's input validation (e.g. the user inputs an empty name)

- If it can't happen and shouldn't, that's a contract (e.g. I checked that this string is non-empty in the function that calls this one, so I already know it's non-empty. Also my linked list has a head and a tail because that's how my constructor made it)

Most bugs happen in the space of things that the programmer thinks shouldn't happen but happen anyways. That is why contracts are useful. But in a bug-free program they also don't do anything, so allowing you to turn them off with a compiler flag is reasonable. Just like asserts, but a bit more useful for tooling, IDEs, etc. Also with an observe mode that allows you to find bugs in production without crashing your whole process

If someone wants contracts in C++, why not just use Eiffel?

Preconditions cannot be checked at compile time in all cases.

In my C compiler rcc I throw compile-time errors of course. Not a full SMT solver like z3, just a self written solver, but it works fine and fast enough. Runtime errors are just glorified asserts, lame.

This is the biggest problem with contracts, there's simply no way to actually say "please always execute this check". A lot of people replying seem to think that the critique is with the concept of contract based programming, but the C++ version of contracts is just weird

The programming model for C++ contracts as described by the authors, and spec, is that they are 'ghost code'. You must never assume that a contract check is actually executed, even if you've asked your compiler to execute your contract checks. This is because ABI/ODR problems can and will cause your contract checks to be deleted, as well as the 'observe' contract mode which is a strange one

So its hard to know what the use case for them is as a result. You can't use them for safety checks, because you must assume they won't be run. Hilariously, they actually introduce safety problems vs asset: Eg take two pieces of code:

    assert(p != nullptr);

    assert(p->some_value());

vs

    contract_assert(p != nullptr);

    contract_assert(p->some_value());

People mistakenly transform #1 into #2 unconditionally, not realising that this is actually a misuse of the contracts feature. It can, and will lead to undefined behaviour - while being perfectly well defined with asserts

I have a feeling that in 10 years the advice will be to never use contracts in anything approaching code that needs safety, as they're generally less safe than using an assert for no real reason. So what's their use case?

    ...
    debug if (x) printf("x: %d\n", x);
    ...

    debug assert(lookMa);

You need to study Bertrand Meyer's "Design by Contract" and "Applying Design by Contract" papers - https://news.ycombinator.com/item?id=48358691

There are also ways to turn runtime contract checks into static verification checks. See my other comment for details/links - https://news.ycombinator.com/item?id=50108112

You should check out the Racket programming language. They actually don’t have types at all in their documentation, they only have preconditions and postconditions which are very helpful in telling you if a function expects non-negative integers or something.

>I'm all for signing up for a contract if it can turn a runtime error into a compile time error.

You can get compile-time errors with static code analysis tools with it but the main goal is to direct the compiler towards optimizations for restricted case, IMHO. If you know beforehand the kind of values you are using then the only sure way to let the compiler know is to write code in such a way that the values you don't expect result in UB, which is not always possible or convenient. Contracts allow a regular way to do the same. It does not mean the compiler will use this knowledge but it will remain in your code and might be used eventually.

For example, if you want to align an integral value on x you can write something like ((value + x-1)/x)*x, however, if x is a power of 2 then you can do (value + x-1) & ~x, which is likely faster. As of now, gcc 16 does not do this optimization even with contracts, but if you recorded this in code, some future compiler might do this. Without contracts the chances for this are much lower.

If you enjoy this style of programming, I wrote a bit on why contracts and capabilities (ie "allocates memory", "performs i/o") are going to become essential for LLM generated code:

https://gavinray97.github.io/blog/design-by-contract-and-eff...

First thing that popped into my mind as well I read the entire book on this and I really enjoy the philosophy

On the one hand, almost everyone (including C++ fans) agrees that the language is too big. On the other hand, comtracts just formalize an existing and useful concept.

Rust is quite complicated but people like it a lot. Python too in a way - it's quite large and complicated but it exposes the complexity in a very gradual way and you can ignore so much of the language and still get things done.

I agree with you about simple languages though. I really like Go - the "there should be only one way to do things" from the Zen of Python actually applies to Go in a way that it doesn't apply to Python at all.

    var i interface{} // (Type: nil, Value: nil) -> i == nil is TRUE
    var p *int = nil  // p is nil
    i = p             // (Type: *int, Value: nil) -> i == nil is FALSE!

Lots of programmers match the right language to the right job, I think the zen of C++ is embracing the ugly as a feature; there are so many subsets of that language you never have to leave it.

I view C++ (and increasingly C# and Java) as a test bed for language features. You throw every possible feature into it and people can then see what makes sense and what doesn't. That allows others to pick features and use them for more opinionated and simpler languages.

Allegedly the pre and post conditions, in varying degrees of certainty according to the evaluation semantics selected, are propagated to the optimization passes of gcc and llvm. However, I haven’t seen any detailed blog posts or summaries of the effectiveness or reliability of this feature. Sorry it’s not a lot of info, but it was what I knew off hand based on previous reading.

I don't get the impression that these are meant to influence optimization at all.

That is not a primary goal. There was a discussion about "assume" semantics, but that is not one of the standardized contract evaluation semantics.

See the papers "Soft Contract Verification" and "Soft Contract Verification for Higher-Order Stateful Programs" (Nguyễn et al.) In general, there's a lot of academic work on the topic coming from the Racket community.

In short: yes, some classes of contracts can be statically proven. Not all of them, and it depends on the language's semantics, so it's probably not easy to retrofit into C++. But there's work being done on unifying types and contracts, moving back and forth between static proof and dynamic enforcement, and it's all pretty interesting. Proving contracts statically eliminates runtime overhead; generating contracts from types makes it possible for a gradually typed language to be sound.

I'm expecting to see talks (and buy books, read blogs...) in 3 years by someone who spent a lot of work adding contracts to a small but significant code base. This is the type of question they will answer.

I think the right answer is in the header, and in turn that means someone needs to answer your objection - how do you avoid long compiler times? I suspect modules is a large part of the answer, which means the guide/talk will also be how to make modules work in the real world. Remember though, that is all guesses I wouldn't be surprised if I'm wrong.

Since this is for C++26, you use modules.

Strictly speaking you put them in the header.

The first declaration of a function must include the contract pre/post conditions and follow-up re-declarations of the function must either not include any contract conditions or the same conditions as the initial declaration.

And you can avoid re-including the world because pre/post conditions should be externally visible behavior or call out to functions for pre/post checks on internal behavior.

Essentially you either define them using what you have in scope during the initial declaration or you call out to a function located elsewhere that can have access to more/internal scope and do more complicated checks.

Same uses as assert, but more options for what to do when they fail and you can move them (pre/post at least) into the function declaration so they act as a kind of executable documentation (when you compile the program so that they are executed and not dropped).

Take a look at Racket (or Rhombus if allergic to parens). Support for contracts there is stellar and provides everything you mentioned. You can use `define/contract` for inline contracts, or you can attach contracts when exporting names from a module using `contract-out` declaration. Contracts are first-class, can be defined separately and attached wherever you want (importantly, this includes values (structs, classes) as well as functions). There are higher-order contracts that generate new contracts from existing ones. There's support for both static and dynamic metadata for almost all kinds of entities in code (ie. both the syntax and the semantic entity it produces can be annotated with anything). I wouldn't recommend using Racket/Rhombus in production, but it's a great preview of what might become commonplace in a decade or two :)

You can set a "contract evaluation semantic" for contracts. One of them is "observe", which only prints a message on contract violations. With "ignore", nothing at all happens.

Graceful handling is a trade off. Sometimes the check is expensive, if everybody normally does it right you don't want to check (particularly in a tight loop), but you don't want to lose this. I work in embedded, in production our CPUs are not powerful enough to risk all those runtime checks, but I want to turn them on when I work on my workstation - in hopes that if there is a problem we catch it.

Contacts are also a guaranteed syntax. Runtime checks provide no way for tools to know if the condition is expected to never happen - this is a bug; vs this is a normal user error we need to check for. A contract means theorem provers can find code paths where a bug could happen - of course we don't have theorem provers for C++, but this is seen as a requirement to get them.

No worries, this will probably land in C as well, static_assert was already.

I have seen far too many times when the comment in the implementaiton doesn't match reality to accept pre/post conditions in a comment. I want my contracts someplace where they get evaluated from time to time so that they are fixed when they are wrong.

An anthropic employee did a talk earlier this year or last and i think it was said that yeah, they eat it up. Tools to find errors because it is visible is great