On Wed, Oct 15, 2025, 14:10 Timur Doumler via SG15 <sg15_at_[hidden]>
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.
>
> 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 —
>
P2900 suggests that the contract semantics are selected by the one that is
responsible for building the application, not the library writer.
If the library uses a different tool that is not the contextual keywords,
and thus allows different semantics for the library than for the
application - is this within 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
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>