Date: Thu, 19 Feb 2026 16:43:04 +0200
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 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.
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.
> 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.
It isn't based on any such thing. It's based on whether a conclusive
proof can be formulated, and that has no guesses nor heuristics in it.
AT ALL.
See next bit.
>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.
<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 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.
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.
> 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.
It isn't based on any such thing. It's based on whether a conclusive
proof can be formulated, and that has no guesses nor heuristics in it.
AT ALL.
See next bit.
>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.
Received on 2026-02-19 14:43:17