On Thu, 19 Feb 2026 at 16:06, Jan Schultke via Std-Proposals
<std-proposals@lists.isocpp.org> 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.
Sure, such warnings could be emitted, and -Werror could turn them into
actual compilation failures, but
1) that's actually non-conforming
2) and that's by design in contracts
Also, we don't have anything of the sort of what's being proposed
here, in contracts. All that stuff is completely hypothetical, and no
implementation
of warning about contract violations exists in a compiler.
I don't think it really matters whether -Werror is conforming or not. Users opt into the non-conformance explicitly.
And you don't need to do anything in the standard to get the behavior out of contracts. Sure, static analyzers don't yet diagnose contract violations, but that's because it's a brand new feature. I would expect static analyzers to do that eventually.
What OP proposes could also be done separately from static analysis as a compiler flag that requires the compiler to prove all contracts hold. This essentially turns contract_assert into OP's compile_assert when the semantic is ignore. In any case, I think contracts are the right way to express conditions that should hold.
That's not a false positive. This facility asserts that a condition
can be proved true, and if it can't, compilation fails.
That's the *cost* of using this facility in code where such a proof
cannot be constructed, but that doesn't make it a false positive.
It's a false positive in the sense that there are cases where the compile_assert is never going to trigger when looking at the whole program (sometimes figuring this out is just one optimization pass away), but the assertion can trigger anyway. It can also trigger for dead code like functions that are never called, but would have been optimized out later by the linker. I guess you could also look at it like
Please compiler, try figuring out if this condition is true when looking at this piece of code locally, and if it's false or you're not sure, error.
... then there are no false positives since it's just a polite request for best effort. The issue I see is that there's no good way to formulate this polite and extremely fragile request in the standard other than making the mechanism completely unspecified.
>There aren't rules we would want to put into the standard and actively maintain for this. The rules are all QoI.
Yes, QoI they are, because they depend on how much work an optimizer
does. But that work isn't guesses nor heuristics.
Alright; it's only not based on heuristics because the feature wants to aggressively fail, essentially preventing false negatives by making the compiler explode. False positives can still happen due to insufficient optimization, which is sometimes the consequence of bad heuristics (like deciding not to inline).