Hi Jan

Many thanks for your reply and reviewing my proposal.

On 19/02/2026 14:05, Jan Schultke wrote:
> I think what you're asking for should in some way be covered by contracts. In some sense, we already have exactly what you're proposing. Static analyzers in compilers can check whether unconditional contract violations are taking place, and you can -Werror on the emitted warnings.
>

Would be great to take a look at some contracts that work at compile time. I do like Static analyzers, is there a particular one you could suggest to see unconditional contract violations are taking place?

> I don't think there's much potential for putting this into the standard otherwise (maybe even with contracts). Say you have a compile_assert that checks that an argument is not null, and you call the function with nullptr. The optimizer knows after inlining and constant folding, the compile_assert is violated. However, what if that unconditional call happens in a branch that is never entered because it sits in if(false)several layers of code away? Consequently, the feature you're proposing has both false positives and false negatives except for whole-program optimization.
>

If there is something like this the if(false) would be optimized out as far as I can see in my own checks. Am I missing something? If you have an example I'd like to look into this more, could you share something.

Just compiled this:

#include "compile_assert.h"

#include <iostream>

int main()
{
    const bool my_feature = false;
    int a = 1;
    if(my_feature)
    {
        compile_assert(a != 1, "");
        compile_assert(a == 1, "");

        std::cout << a << "\n";
    }

    return 0;
}

This might be a programmer retaining in some old reference code, I've seen this used for custom builds, so features can be enabled again for another future deliverable, different customer config etc. If I renamed that variable 'a' to 'missing' within the if(), it wouldn't compile, so it helps me keep all code paths compiling (even if optimizer removes the dead code later)

> Since there are both false positives and false negatives, it should be up to compilers to keep the number of both false diagnostics low. This is all based on wishy washy guesses and heuristics. There aren't rules we would want to put into the standard and actively maintain for this. The rules are all QoI.
>

Can you think of an example that would give false positives and negatives? I'd like to look into this more.

After reading your message, I amended my thinking, as you say, it should be up to the compilers to keep the number of false positive diagnostics low. So I amended the proposal would be to standardize only syntax of compile_assert(expression, message), and not add any specific requirement for the C++ compiler prove certain complicated conditions, this would be left up to the compiler to decide how much time is spent optimizing. So users get a standard keyword, and they don't get a full warranty everything will be caught. There are many intractable programming questions. This comes into the Halting Problem by Turing.

Thank you again for the feedback.
Jonathan


> On Thu, 19 Feb 2026 at 14:40, Jonathan Grant via Std-Proposals <std-proposals_at_[hidden] <mailto: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 <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] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>