On 21/05/2026 23:42, Sebastian Wittmeier via Std-Proposals wrote:
> That would make the diagnosis dependent on the quality of the "prove engine", of the compiler or static checker settings, possibly of half-unrelated parts of the program (e.g. one indirection more).
>
> Just saying. That all could be okay and reminds of automatic checking for C++ contracts.
>
> One approach could be that a tool that first proves some "fact" creates some machine-only- or also user-readable marking how the proof was done. So other systems can revisit the proof, even if they are less sophisticated. That would give more reliability and stability. And it would also give (more) suitable error messages, if the proof is not viable anymore after a change in the code.

That's a good point, would be be useful if vendor compilers outputted proofs from their control flow analysis. Maybe it's visible in the intermediary files.

Any code change that causes a constraint failure will clear in the build diagnostic warning/error compile time contracts like compile_assert P4021.

This negates the need for C++26 runtime contract assessment - impossible to prove 100% a runtime C++26 contract is satisfied if the compiler's control-flow analysis cannot remove the runtime contract code.. because the C++26 contract is still referenced in the resulting ELF.

I put some slides together earlier this year
https://github.com/jonnygrant/compile_assert/blob/main/slides/compile_assert_cpp_london_March_2026.pdf

Do you think it's more useful for functional safety to be validated at compile time?

Regards, Jonathan

>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Alejandro Colomar via Std-Proposals <std-proposals_at_[hidden]>
>
> trap; // diagnosed unless proved unreachable.
>
>
>
>