On 10/14/25 7:21 PM, Ville Voutilainen wrote:
> On Wed, 15 Oct 2025 at 02:12, Tom Honermann<tom_at_[hidden]> 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.
Fair enough, and similar with respect to the behavior of a hardened
precondition failure being independent from the selected contract
semantic for user written contract assertions.
>
> 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) <https://wg21.link/p3471r4>. Section 8.1, "Contracts"
<https://wg21.link/p3471r4#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
<https://eel.is/c++draft/structure.specifications#3.5> doesn't seem to
retain that flexibility; /contract assertions/ is a defined term
([basic.contract.general]p1
<https://eel.is/c++draft/basic.contract.general#1>)) 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]
        <https://eel.is/c++draft/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 <https://wg21.link/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 <https://wg21.link/p3835r0>, P3853R0
<https://wg21.link/p3853r0>, and P3829R0 <https://wg21.link/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.