On Sun, 16 Aug 2026 at 00:31, Jonathan Grant via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hello
>
> Sharing my notes and feedback after reading.
>
> I read P4334R0:
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4334r0.pdf
>
> Is it possible to review/reconsider P2900 until this approach for Contracts have had more time for field use?
>
> BTW, there is also a broken (404) link in P4334R0 to D4324R0:
> https://isocpp.org/files/papers/D4324R0.html
>
> Could someone point me to the paper?

That would be https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4324r0.html

The D-links unfortunately break when published as P.

> If there was scope to consider a simpler approach, which places emphasis on compile-time checks that would be very useful for functional safety. Runtime checks are risky.
>
> Relying upon a contract violation being detected at runtime has issues. The violation may occur only after deployment, and runtime checks may potentially be marked 'ignore'. The contract-violation handler also introduces a runtime path which cannot necessarily be shown at compile time to be unreachable. For functional safety, it's an unknown, if it will be called.

I have an implementation of the P2680 "strict contracts", of "symbolic
contracts" that we don't yet have a proposal for, and various forms
of static analysis for both. I'll eventually write papers describing those.

As for your compile_assert, based on the implementation of the
aforementioned, I have the means to prototype-implement it under any
proof-requirement rules you like. Not as "just give a result based on
whether the compiler was able to optimize-prove this is a constant"
like it is now, any rules.