On Wed, 15 Oct 2025 at 02:12, Tom Honermann <tom@honermann.net> wrote:

My expectation is that standard library implementations will not tie
their choice of a contract semantic for hardened precondition to any
particular choice of contract semantic for user written contract
assertions and will instead rely on some other implementation dependent
way to select a contract semantic for hardened preconditions. Do you
have a different expectation?

I expect that the implementations won't be using contracts, and won't
be using such a suggested
implementation-dependent way to select a contract semantic, because
using such an implementation-dependent
way requires a library implementation to possibly use three or more
different ones, if that many or any even exist.

Doing that also has the significant advantage of being exactly the
same implementation for the pre-standard hardening
and the standard hardening, while being fully conforming to the
standard specification.

So your objection is that C++26, as currently specified, requires that a hardened precondition evaluated with the enforce semantic result in a call to the contract violation handler?

There does seem to be an inconsistency in P3471R4 (Standard library hardening). Section 8.1, "Contracts", states:

It is useful to note that we don’t require implementations to actually implement these checks as contract assertions. Implementations are free to implement precondition checking however they see fit (e.g. a macro), however they are required to employ the contract violation handling mechanism when a precondition is not satisfied.

However, the wording added to [structure.specifications]p3.5 doesn't seem to retain that flexibility; contract assertions is a defined term ([basic.contract.general]p1)) that applies only to pre, post, and contract_assert.

Hardened preconditions: conditions that the function assumes to hold whenever it is called.

• 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 ([basic.contract.eval]). If any of these assertions is evaluated with a non-terminating semantic and the contract-violation handler returns, the program has undefined behavior.
• When invoking the function in a non-hardened implementation, if any hardened precondition is violated, the program has undefined behavior.

I had been under the impression that hardened preconditions did not require use of the contracts language features (consistent with the quoted note above). It seems that P3471R3 had more flexible wording (and is the revision that LEWG and EWG polled). R3 stated:

Hardened preconditions: the conditions that the function assumes to hold whenever it is called; violation of any hardened preconditions results in a contract violation in a hardened implementation, and undefined behavior otherwise.

This is already covered in the section of my paper under the title "Is
this QoI?"

I've read P3835R0, P3853R0, and P3829R0, but none of those have a section by that name. Is there a newer revision or another paper that I'm not aware of?

Tom.