On 10/14/25 4:08 PM, Ville Voutilainen wrote:
> On Tue, 14 Oct 2025 at 22:59, Tom Honermann via SG15
> <sg15_at_[hidden]> 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 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.
>
> 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
<https://github.com/llvm/llvm-project/blob/20bcf123e2db033f208462f34f63e292efbe0946/libcxx/include/__assert#L44>
and related macros (see here
<https://github.com/llvm/llvm-project/blob/20bcf123e2db033f208462f34f63e292efbe0946/libcxx/include/__assert#L20-L24>,
here
<https://github.com/llvm/llvm-project/blob/20bcf123e2db033f208462f34f63e292efbe0946/libcxx/vendor/llvm/default_assertion_handler.in#L40-L60>,
and here
<https://github.com/llvm/llvm-project/blob/20bcf123e2db033f208462f34f63e292efbe0946/libcxx/include/__verbose_abort#L40-L46>).

Tom.