On 10/15/25 7:10 AM, Timur Doumler wrote:
> Specifically about the inconsistency that Tom highlighted:
>
> Please correct me if I'm wrong, but if I remember correctly, we
> discussed this point specifically when reviewing the P3471 wording in
> CWG+LWG. From what I remember, the outcome of that discussion was that
> we can (and did) write in the wording that the standard library is
> using contract assertions as defined in the core language (`pre`,
> `post`, and `contract_assert`) but that does not actually imply that
> those keywords are physically present in the standard library
> implementation, only that the standard library behaves as if they were
> there.
I wasn't present for that discussion, so I can't offer any confirmations
or corrections.
>
> In other words, if a standard library implementation internally uses
> macros — or some other implementation-defined mechanism — instead of
> the contextual keywords `pre`, `post`, and `contract_assert`, then
> that implementation is still conforming with that wording as long as
> the observable behaviour is the same as if those keywords were used —
> because the wording does not prescribe what tokens are used to
> implement the standard library, only how it behaves.
>
> To the best of my memory, this intent was explicitly discussed and
> acknowledged and everyone in the room was fine with that.
>
> Does this information resolve the inconsistency?

An as-if argument seems reasonable to me so, yes, thanks.

Tom.

>
> Cheers,
> Timur
>
>> On 15 Oct 2025, at 08:03, Tom Honermann via SG21
>> <sg21_at_[hidden]> wrote:
>>
>> 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.
>>
>> _______________________________________________
>> 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/11314.php
>