Date: Tue, 18 Aug 2026 20:48:05 +0100
On 15/08/2026 22:40, Ville Voutilainen wrote:
> 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.
Thank you.
>
>> 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.
Would be interesting to see when you have it.
> 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.
Would be pleased to see, if you have a godbolt link to a simple example demonstrating, if it can stop the build when an invariant is determined invalid. For example decompressing some data into a fixed sized buffer - which may overflow the fixed sized buffer.
My slides about compile_assert from earlier this year have some common examples I am interested in, for program correctness, detecting at compile-time
https://github.com/jonnygrant/compile_assert/blob/main/slides/compile_assert_cpp_london_March_2026.pdf
With kind regards
Jonathan
> 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.
Thank you.
>
>> 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.
Would be interesting to see when you have it.
> 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.
Would be pleased to see, if you have a godbolt link to a simple example demonstrating, if it can stop the build when an invariant is determined invalid. For example decompressing some data into a fixed sized buffer - which may overflow the fixed sized buffer.
My slides about compile_assert from earlier this year have some common examples I am interested in, for program correctness, detecting at compile-time
https://github.com/jonnygrant/compile_assert/blob/main/slides/compile_assert_cpp_london_March_2026.pdf
With kind regards
Jonathan
Received on 2026-08-18 19:48:12