On Thu, Sep 10, 2026 at 4:44 AM Peter Bindels via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> ...
>

Hi Peter,

Thanks for the significant engagement. The godbolt examples, the
implementation notes on GCC and Clang, and the close reading of P4363 are
very helpful especially for the wider audience.

One sentence in your reply needs a correction:

In a way, profiles *is* compile-time proving that a given guarantee holds,
> not actually too dissimilar in spirit from compile-time proving contracts,
> just with a wider scope.


Profiles are not the compile-time half of an arrangement in which contracts
keep the runtime. P4317 specifies the intended model: a profile owns the
guarantee, the enumeration of what is checked, and the response when a
check fails. Some of that response happens at compile time, some at
runtime, and the profile decides which. P4324 (Section 4) specifies
contracts and profiles as independent peers.

The summary "contracts do the runtime machinery, profiles do the
compile-time proving" reads as agreement, but it answers an open question
before the question is polled. Who owns the response to a violation of a
core-language rule is contested. P4297 asks it directly and argues it
should be polled by name; P4306 compares the two configuration models.

The same applies to the remark that postponing contracts would cause issues
for "anything else that tries to rely on their specification for runtime
checks and failure handling." Which features are those? Profiles as
specified do not rely on the contracts machinery for their response. That
independence is the point of the design.

Your demonstration that P2900 can mimic compile-time checking by leaving
the violation handler undefined came with your own assessment: fragile, and
not usable in general. I agree. The compile-time checking story for
contracts is not settled, and proposals like Jonathan's should be evaluated
on their merits rather than treated as already covered. And in your review
of P4363 you observed that the current modes include "two of which
guarantee not continuing into the code whose preconditions was broken."
That is the property the safety discussion keeps returning to: the response
that matters does not continue into a state the language does not define.

Since the point surfaced several times in the thread: nobody here argues
against the violation handler being invoked, or against logging. Where the
state after a violation is still defined, as with library-level checks such
as Bloomberg's bsls_review, log-and-continue is good. What some of us
contest is narrower: continuing past a violation of a core-language rule,
into a state the language does not define, as the default and portable
response.

Thanks again for engaging on the substance. I would urge everyone to keep
these two questions separate going forward: who owns the response to
undefined behavior, and what the response should be.

Best