On Thu, 19 Feb 2026 at 17:43, Jan Schultke <janschultke_at_[hidden]> wrote:
>>
>> Also, I don't think that having this feature would have made contracts less necessary. None of the current contract evaluation semantics do what OP is asking for. However, it would be possible to add a fifth "proof" contract evaluation semantic, one step up from ignore. That makes it seem to me like what OP proposes provides additional motivation for contracts in their current state, since our C++26 design could be extended to provide everything OP is asking for.
>
>
> Now thinking about, making compile_assert a use of contract_assert with "proof" contract evaluation semantics also solves the issue of optimization levels.
>
> The user can control what contract evaluation semantic is chosen using build flags, just like optimization levels. To prevent unusable debug builds, the user could simply use ignore or enforce semantic on debug builds (with -O0) and "proof" semantic on optimized builds (-O3) instead of ignore. If the feature is tied to contract semantics, we don't need to introduce a notion of optimization levels into the standard.
>
> Not to pat myself on the back too much, but I think this is brilliant.

It also doesn't work at all, because next to no user of this facility
wants the contract evaluation semantic configuration to turn this
assert completely off.
And they certainly don't want the act of turning off runtime checks to
also turn off all compile-time checks.

So, brilliantly mistaken and misconstrued.