On 19/02/2026 14:47, Ville Voutilainen wrote:
> On Thu, 19 Feb 2026 at 15:40, Jonathan Grant via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> Hello,
>>
>> I am interested in mechanisms that provide better compile-time guarantees than static_assert, I don't want to introduce runtime checks that call abort().
>>
>> Is there any current or active standard proposal that addresses this at compile time? I did look at C++ contracts, they seem to be runtime enforced.
>>
>> If not, I would like to propose a compile_assert() that leverages the compiler's optimizer to verify control-flow constraints at build time. If there is a template, I can write up formally.
>>
>> I am aware that various workarounds have existed for many years. However, my requirement was for a solution that fails at build time, not at runtime. In safety-critical systems, a runtime failure that results in std::terminate() or abort() is unacceptable.
>>
>> I have been using a compile_assert() approach in production code for several years. It verifies constraints at build time and stops the build if they are violated. Significantly reducing the likelihood that serious defects reach released code.
>>
>> Although the approach has limitations, it has proven effective in real-world code. If you are interested, details and examples are available here:
>>
>> https://github.com/jonnygrant/compile_assert/blob/main/README.md
>>
>> Some issues cannot be validated at compile time, many can. Some constraints can only be verified within a single translation unit, my github repo includes approx 14 examples demonstrating common use cases and mitigation strategies.
>>
>> For example, compile_assert() can detect cases where a nullptr might propagate unchecked, forcing the developer to address the issue at build time. I have found this particularly useful in safety-critical software. Applicable to aviation, space, automotive, medical systems; where failure at runtime is not acceptable.
>>
>> I understand that in many environments a core dump is considered sufficient (although when it restarts, often the core dump happens again). However, in certain systems, especially those requiring high reliability, preventing the issue from compiling in the first place is preferable. On modern CPUs, the 'cost' of these guarantees, eg a branch is often impossible to notice, compared to the risks of downtime.
>>
>> The approach has also proven useful in detecting potential memory overruns, such as buffer boundary violations when processing variable-sized compressed data.
>>
>> If anyone wants to make use of my compile_assert() on safety critical platforms, I'd be happy to have more examples of usage, and any improvement ideas.
>>
>> Of course I have something that works, so I can keep using this way. Although a formal addition to the C++ language spec would hopefully mean the compiler output when it fires could be more specific.
>>
>> I would welcome any feedback on the concept.
>
> The facility is fantastic. But standardizing it is hard, because it is
> based on how much work your optimizer does, and whether optimizations
> are enabled.
> That would make the specification of the facility vague, and makes it
> hard to specify it at all in any meaningful way.
>
> I do want to thank you for bringing it up, though - the facility is,
> as I say, fantastic, and this is a fantastic addition to the toolbox
> of various programmers
> and projects.

Hello Ville
Many thanks for reviewing the idea.

You're right, compile_assert relies entirely on the optimizer's output, which varies by build config and specific optimization level, and the complexity of the code. It only works in optimized builds, and even then not 100% consistently across complicated cases (like heavy math). Although in practice for non-complex straightforward invariants (buffer index bounds checks, nullptr checks) GCC and Clang do both warn about the same issues I need in my experience.

If compile_assert cannot make the expression constraint hold, I remove it. That's a clue I need to re-factor (maybe smaller files, simpler containers), focus on runtime error handling and add proper recovery instead of relying on compile-time checks. On a related topic, I occasionally introduce a testing function to cause deliberate failures to verify the recovery logic works after I have made changes compile_assert identified.

I put my compile_assert "edit" working copy on github, I'm getting ready for a future update, it has more information, and I would be delighted to have feedback.
https://github.com/jonnygrant/compile_assert/blob/main/proposal/compile_assert__isocpp__P4021Rx_edit.pdf
 
> For different approaches in trying to bring forth static rules that
> are enforceable, I recommend looking at the various papers on
> Profiles,
> and also https://wg21.link/p3285

Thank you for the link, I will review and Profiles.

Thank you again for the help reviewing.

Regards,
Jonathan