Thank you for that - it does clarify things for me. It is usually the
case for new C++ features that the initial introduction is somewhat
limited, and later standard versions extend them as details are fleshed
out and both users and implementers get some experience about what is
actually useful in practice, and what people would like to see added.
But it is helpful to hear about what is already in planning.

(I seem to be having a little trouble with my email sending at the
moment. I apologise if that results in any duplicates, or if it only
gets to some of the addressees.)

David


On 02/04/2026 13:04, Jonathan Wakely wrote:
>
>
> On Tue, 31 Mar 2026 at 09:05, Jonathan Wakely <cxx_at_[hidden]
> <mailto: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.
>
>
>