On Thu, 19 Feb 2026 at 15:43, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:

> On Thu, 19 Feb 2026 at 16:06, Jan Schultke via Std-Proposals
> <std-proposals_at_[hidden]> 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).