Hi,

Adding to what Herb said:

> On 17 Oct 2025, at 17:23, Herb Sutter via SG21 <sg21_at_[hidden]> wrote:
> No, that’s not my understanding: Any assertion facility that offers log-and-continue (or similar “observe”) semantics will have the same issue.
>
> Many assertion libraries do offer that, don’t they? I did a quick Google search (errors are mine):
> It seems that BOOST_CHECK and BOOST_TEST both continue, and so would have the same issue with this example.
> Various assertion frameworks support a custom violation handler that could return instead of terminate/abort. If they return and do not abort, those would have the same issue again.
> It’s true that C assert() specifically doesn’t have that problem, but that’s only because it’s not powerful enough – it only offers “ignore” and “quick_enforce.” We do need observe semantics (we’ve already added it in our assertion libraries when C assert wasn’t enough), and as far as I can see any assertion facility with that feature has to have this characteristic for this example. So it seems to me this is a feature, not a bug.

Yes exactly, and may I point out also that the observe mode in C++26 Contract is strictly *better* than an equivalent observe mode in an existing assertion macro, because with the assertion macro, if you have UB after continuing past a violated assertion then the whole program is UB and the entire assertion might be optimised out, whereas with C++26 Contracts we made sure this cannot happen by specifying that a contract assertion (including an observed one!) is an observable checkpoint which means even if UB follows, you still have a guarantee that the check happens and any output from the contract-violation handler also still happens before you hit the UB.

Cheers,
Timur