Does this mean that this can/will behave differently depending on what
optimization levels you may have enabled on the compiler? -O3 and it
can pass the compile_assert(), -O0 and the compile_assert() fails?
If so, this could be troublesome in the context of the Standard since
it doesn't currently acknowledge "optimization levels".

On Thu, Feb 19, 2026 at 5:40 AM 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.
>
> Jonathan
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals