Contracts
C++26 contracts were talked about quite a bit this year. Nowhere near as much as reflection… or AI, but still a respectable amount. Think of these as the Andy Murray of the C++ world. Absolutely fantastic, and would dominate if they existed at any other period in history, but they exist at the time of reflection and AI, so they aren’t quite as exciting.
Overview
Herb gave a talk called “The Joy of C++26 Contracts”, and it was a great primer for what contracts are, and what the current state of them are.
The following is a brief overview of contracts.
Pre and post conditions are written as part of the function signature using the pre and post contract specifiers.
There is an additional statement called contract_assert. This has the same semantics as assert in <cassert> (or check in Unreal Engine).
Unlike pre and post, contract_assert lets you assert from within the body of a function.
There are 4 “assertion semantics”
Warning
The CppReference page on Contracts lists enforce and quick_enforce as having the same semantics… However, Herb Sutter and John Lakos made it quite clear in their talks that the above is correct. But there does seem to be some contradictory
information when it comes to quick_enforce, so bear that in mind :)
These semantics are set at compile time through some compiler switch, and are quite reminiscent to what we have with check in Unreal Engine right now. In Development configs we effectively have the enforce behaviour for check. i.e. There is some crash handling code run, then we terminate. Unreal also has ensure which if you squint, kinda looks like it has the observe behaviour. ensure in Unreal Engine will break if a debugger is attached to allow devs to observe the violation, but it does not terminate… Yes, it is not exactly the same, but comparable at least.
Contract-violation handlers seem to be one of the improvements over current assert features. The contract-violation handler is a function that you can provide which will be called when an assertion is hit with the enforce or observe assertion semantics. The function takes a std::contracts::contract_violation which has some information about the assertion that failed. It is all quite neat!
A Caveat
Though Herb named his talk “The Joy of C++26 Contracts”, there is still a chance that they won’t make C++26. I believe that decision will be made in Kona. It was quite clear during the Fireside Chat with the committee, that Bjarne is vehemently against contracts making C++26. He likes the idea of contracts but does not believe that they are ready yet. Among the objections that Bjarne raised were:
- We don’t have enough experience with them
- There are ODR violation concerns
- We don’t know how they will work with C++ modules yet
I will note here that none of the others in the panel seemed to agree with Bjarne. Daisy Hollman saw them as extremely important for LLMs because they act as great annotations for functions to express intent, which really helps LLMs “understand” your code. Others completely disagreed with the idea that we don’t have experience with them because there are implementations being used right now, and they do work. I found Bjarne’s objections quite disheartening in one way because contracts have had such a troubled story. In John Lakos’ talk, “What C++ Needs to be Safe”, he went through the history of contracts as a feature. I was amazed to find out that they began life all the way back in 2003!
So, hearing that there are still questions and objections after 22 years was just a bit sad. On the other hand, this whole disagreement that was happening live on stage did make me feel a little more confident in the C++ committee. It is not just filled with “yes people”. Everyone speaks their mind, and they seem to engage in the disagreements like adults. They all care about the future of C++ and genuinely want to make the right decisions. This was a point well made by Nina Ranns.