Isn’t P2900 in the DIS that’s currently out for national body ballot?
You’d have to convince a number of countries to vote down C++26 at this
point, no?

On Sat, Aug 15, 2026 at 2:31 PM 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?
>
> I read P4332R0 too
> https://isocpp.org/files/papers/P4332R0.html
>
> I have some concerns about C++ Contracts.
>
> At a conceptual level, contracts are Hoare logic: precondition, command,
> postcondition. That underlying idea is simple, whereas the C++ Contracts
> specification appears far more complicated.
>
> 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.
>
> This is relevant to functional-safety software, where it is important to
> demonstrate that a violation handler cannot be called, rather than relying
> on it to catch a violation at runtime. Which leaves the question what to
> do, when it is called. Hard to prove, if the symbol is present and linked
> to.
>
> My own proposal, compile_assert(), P4021, explores a different approach:
> https://wg21.link/P4021
>
> compile_assert() operates at compile time and deliberately has a very
> small implementation model. Naturally, it can only verify properties which
> the compiler is able to determine at compile time.
>
> As an experiment, I have implemented contract-like checks in terms of
> compile_assert().
>
> https://github.com/jonnygrant/compile_assert/blob/main/testsuite/main28_a.cpp
>
> I have also recently experimented with compile-time checking of Ownership,
> Optional values, and a Forget abstraction. These experiments suggest that
> quite a lot of misuse can be detected at compile time, including some of
> the particular errors Rust is good at catching.
>
> I would be very interested in feedback from anyone who has experimented
> with P4021 or has thoughts on how far C++ contract checking could usefully
> be moved towards compile-time.
>
> Finally, P4332R0 appears to have some character-encoding issues in the
> reference to P2899R1. Could the editor take a look at that?
>
> Kind regards
> Jonathan
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>