*Ville:*
> They don't seem to succeed at what you're telling them to be designed for:
https://isocpp.org/files/papers/D3878R0.html

The first concern in D3878R0 is that in a conforming hardened
implementation, it is possible for a contract violation not to result in
program termination. That is the concern you mention
in [structure.specifications]/3.5.1. Reproducing the wording here:

When invoking the function in a hardened implementation, prior to any other
observable side effects of the function, one or more contract assertions
whose predicates are as described in the hardened precondition are
evaluated with a checking semantic (6.11.2). *If any of these assertions is
evaluated with a non-terminating semantic and the contract-violation
handler returns, the program has undefined behavior*.


You basically don't want `observe` to be a conforming Hardened
Implementation. I'd be fine with that. I don't remember why the wording
ended up allowing it, but I think it would be fine to remove `observe` from
the set of allowable semantics for a Hardened Implementation. I don't think
that contradicts the design intent. In a way, that's mostly a "marketing"
distinction: In practice, that means you can still select `observe` or
`ignore`, but that won't qualify as a Hardened Implementation. I think that
achieves the best combination of usefulness and a formal guarantee of
termination under "Hardened" mode.

But, just to be clear, many large adopters will need the ability to select
the observe semantic in order to deploy this at a large scale. That's an
extremely useful tool to have. I don't care if that's not called a
"Hardened Implementation", but it should be possible.

The second concern is about how standard library code can be written to
produce a hardened implementation. In the C++26 timeframe, since Contracts
are a MVP, producing a hardened implementation will basically require the
user to select a set of appropriate evaluation semantics (e.g.
quick_enforce or enforce) throughout all TUs that use the Standard Library,
or the compiler to implement a tagging extension on top of the Contracts
MVP. Once we have a standardized tagging mechanism, we'll be able to expand
the set of valid Hardened programs to also include (for example) the
standard library using `quick_enforce` but the user code using `observe`,
and to do so in a way that is portable. In practice, I expect this to mean
that in order to get an official "Hardened Implementation" in C++26 you'll
want to use terminating semantics throughout your whole program. That
doesn't make Contracts any less useful on their own or in combination with
hardening, it just means that you'll need to abide by stricter rules than
perhaps necessary if you want the official "Hardening Implementation"
stamp, until we have a tagging mechanism.

*TLDR: I think the first wording suggestion in your paper makes sense. That
makes only `enforce` and `quick_enforce` be valid evaluation semantics for
Hardened Implementations and removes `observe`. Contracts and hardening are
still useful with the Contracts MVP, and they'll be more useful once we
have additional Contracts features like tagging. That's not a reason to
kill either.*

Cheers,
Louis

On Tue, Oct 14, 2025 at 2:53 PM Ville Voutilainen via SG21 <
sg21_at_[hidden]> wrote:

> On Tue, 14 Oct 2025 at 21:42, Ryan McDougall <mcdougall.ryan_at_[hidden]>
> wrote:
> >
> > Sorry, this is a weakness of the medium -- what I'm saying is "no one is
> producing inline functions that are promised to be hardened in a legally
> binding way, such as in safety critical applications" -- precisely because
> putting hardening in source that is copy-pasta into a TU weakens the
> promise. It's the legally binding promise of hardening that's at stake. If
> your user is determined to defeat your library-level hardening, you cannot
> control that. Fighting your users is a battle that can't be won. You give
> them library hardening, and they either enable it or they don't.
>
> The concerns is not about expert users being able to turn hardening
> off. They can do that, and that's fine. The concern is about more
> innocent
> users turning the hardening off accidentally by merely linking in another
> TU.
>
> > What I'm saying is that hardened library writers do not rely on
> inlining. The standard library occupies a bit of a unique space since it
> has (to try) to be all things to all people -- including the people who
> cannot imagine a reason why hardening should be turned off. Even if P2900
> is somehow universally declared unsuitable for the standard library, this
> has no bearing on whether P2900 is necessary for Functional Safety. Neither
> the standard library nor GSL are the only or primary users of contracts.
>
> I don't think any of us have information on who the primary user is,
> but in contrast to what you said, users in your domains (which happen
> to be
> the domains of some others of us, too, and we don't exactly agree with
> your take for those domains, either) are also not the only users of
> contracts.
> _______________________________________________
> SG21 mailing list
> SG21_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> Link to this post: http://lists.isocpp.org/sg21/2025/10/11272.php
>