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.

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?

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