Date: Mon, 17 Aug 2026 13:22:19 +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.
I would be pleased to read 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.
Interesting, do you have control-flow analysis?
I like it when the compiler proves, because I know the proof is valid for the machine code generated. If using a separate tool, we would be unable to state it was proven by the compiler that generated the compiled program.
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.
I would be pleased to read 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.
Interesting, do you have control-flow analysis?
I like it when the compiler proves, because I know the proof is valid for the machine code generated. If using a separate tool, we would be unable to state it was proven by the compiler that generated the compiled program.
Kind regards
Jonathan
Received on 2026-08-17 12:22:26
