I read Ran's comment as suggesting that contracts would never be a good fit for standard library hardening. I acknowledge that P2900 does not suffice, without additional implementation provided guarantees, to implement standard library hardening. But it doesn't require much extension to fit that role.On Tue, 14 Oct 2025 at 22:59, Tom Honermann via SG15 <sg15@lists.isocpp.org> wrote:One of the fundamental aspects of p2900 is that the person who write the contract is not the one who selects the semantics for the application. Is this aspect of contracts aligned with hardened libraries needs? The discussion seems to reveal that not. And therefore the draft paper mentioned earlier seems to be correct - contracts are not good fit for standard library hardening. They are, or will be, once either of P3290 (Integrating Existing Assertions With Contracts) or P3400 (Specifying Contract Assertion Properties with Labels) is adopted.So they aren't, in P2900/C++26.
I quite fail to see what P3290 has to do with this. NDEBUG does not turn the standard library hardening off.
P3290 exposes interfaces that allow a custom assertion facility to integrate with the contracts violation handler. It doesn't enable use of the pre, post, or contract_assert syntaxes for such a facility, so if you want to consider that "not contracts", ok. But the P3290 approach is a close match to what libc++ does today to implement standard library hardening as evidenced by its _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS and related macros (see here, here, and here).
Tom.