>
> 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.