Date: Thu, 2 Apr 2026 12:04:22 +0100
On Tue, 31 Mar 2026 at 09:05, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
> And since the version of contracts we have in C++26 only allows them to be
> enabled globally or disabled globally, for the whole program, you don't get
> to choose which API boundaries have checks enabled and which don't. So you
> can't use contract checks as performance hints in your code without
> disabling checks at API boundaries between untrusted (or less trusted, or
> less tested) components.
>
I was asked about this statement off-list, and should clarify what I meant.
Contracts in C++26 do allow an implementation to provide more granularity
so that different assertions (or different TUs, or different libraries) can
use different evaluation semantics. But what was standardized for C++26
(the Minimum Viable Product of C++ Contracts) doesn't provide any syntax or
other mechanism for doing that.
So what I wrote isn't really accurate. C++26 does *allow* them to be
enabled or disabled non-globally, but just allowing it doesn't actually
make it possible. You can't do it in portable C++26 code. And you can't do
it in the implementation that's about to ship in GCC 16 (adding support for
labels as an extension could be added in future, but isn't supported
today).
So if you absolutely require the ability to use different evaluation
semantics in different places (and many people do require that), then
you'll need to wait for C++29 which is expected to provide features for
doing that. It was always made clear that C++26 contracts would not provide
every feature on day one, and that some use cases would be supported later.
They're still useful for other use cases today, just not all use cases.
>
> And since the version of contracts we have in C++26 only allows them to be
> enabled globally or disabled globally, for the whole program, you don't get
> to choose which API boundaries have checks enabled and which don't. So you
> can't use contract checks as performance hints in your code without
> disabling checks at API boundaries between untrusted (or less trusted, or
> less tested) components.
>
I was asked about this statement off-list, and should clarify what I meant.
Contracts in C++26 do allow an implementation to provide more granularity
so that different assertions (or different TUs, or different libraries) can
use different evaluation semantics. But what was standardized for C++26
(the Minimum Viable Product of C++ Contracts) doesn't provide any syntax or
other mechanism for doing that.
So what I wrote isn't really accurate. C++26 does *allow* them to be
enabled or disabled non-globally, but just allowing it doesn't actually
make it possible. You can't do it in portable C++26 code. And you can't do
it in the implementation that's about to ship in GCC 16 (adding support for
labels as an extension could be added in future, but isn't supported
today).
So if you absolutely require the ability to use different evaluation
semantics in different places (and many people do require that), then
you'll need to wait for C++29 which is expected to provide features for
doing that. It was always made clear that C++26 contracts would not provide
every feature on day one, and that some use cases would be supported later.
They're still useful for other use cases today, just not all use cases.
Received on 2026-04-02 11:04:40
