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