On 26/03/2026 21:41, Adrian Johnston via Std-Proposals wrote:
> Hello,
>
> I would like to propose [[assume_assert(expr)]] which would be a
> hybrid of contract_assert and [[assert(expr)]] that selects between
> the behavior of the two depending on the evaluation semantics mode as
> described in P2900:

Hi Adrian

May I check, would behaviour would change depending on settings? I've seen similar discussed before, I recall it was one of the comments re compile_assert() https://wg21.link/P4021 compile time assert, there is no runtime code, it is not present in any object file, it relies on control flow analysis.
 
For functional safety it's a risk to have different behaviour in the same constraint expression/declaration/attribute/function. It feels safer to validate constraints at compile time, rather than runtime. Difficult to certify safety cortical software when there is runtime behaviour that might terminate or call a callback.

>
> - ignore: same as [[assume(expr)]]
> - observe: same as contract_assert(expr)
> - enforce: same as contract_assert(expr)
> - quick-enforce: same as contract_assert(expr)
>
> These have the benefit of alerting the developer in a debug build when
> [[assume(expr)]] has been misused and hopefully reduce the amount of
> undefined behavior associated with the use of [[assume(expr)]].
>
> As an alternative to this approach, an evaluation semantics mode
> "assume" could be added which would convert all P2900 contract
> assertions to have [[assume(expr)]] semantics.
>
> proposed evaluation semantics:
> - ignore: unchanged
> - observe: unchanged
> - enforce: unchanged
> - quick-enforce: unchanged
> - assume: replace pre(expr), post(expr), post(ret, expr),
> contract_assert(expr) with [[assume(expr)]] semantics.
>
> The one major issue here is that the current standard says an assume
> statement cannot call functions, and this limitation would not be
> enforceable across a non-trivial application. Instead, I would propose
> that function calls would result in the expression being ignored when
> evaluation semantics are set to mode "assume". In this case a warning
> would not be recommended as that would break strict builds.
>
> I have implemented this kind of [[assume_assert(expr)]] using
> compiler-specific intrinsics and used it for every last assertion in a
> non-trivial codebase. It worked great, and so I am recommending it for
> the next version of C++26.

Do you have a sample implementation/example on godbolt you could share please. I'd like to try it.
 
> I would also like to suggest things like assume_pre (expr) and
> assume_post (expr) although that pollutes the global namespace for a
> feature that is less commonly used.
>
> My recommendation would be to add [[assume_assert(expr)]] and
> evaluation semantics mode "assume".
>
> Regards,
> Adrian

While it is tempting to add more keywords, APIs etc, like assume_pre, post etc, maybe it is simpler just to have one keyword like compile_assert(), it makes the proposals much bigger when there are so many. Applications can of course wrap in functions of their own if they want more descriptive names than compile_assert().

eg C++ Contracts implemented at compile time with compile_assert()
https://github.com/jonnygrant/compile_assert/blob/main/testsuite/main25_a.cpp

Regards
Jonathan