Hi Jan,
On 2026-02-19T16:11:54+0100, Jan Schultke via Std-Proposals wrote:
> I can't bring myself not to think of it as a "false positive".
> compile_assert is asking the question "Is it known at compile time that
> this condition is true?"
>
> There are cases where the answer is yes, but the compiler can't prove it,
> so it explodes and gives you a false positive diagnostic.
>
> One could say that this feature has no false positives and false negatives
> when phrasing what compile_assert does in terms of compiler mechanics, but
> that doesn't seem helpful. When the compiler gives you an error when it
> theoretically shouldn't, and it only does so due to
> insufficient cleverness, that's a false positive to me. We treat compiler
> warnings as a false positive when that happens.
Some correction: this has false positives, in the sense that when
compiling with too-low optimization level you'll get unnecessary errors.
But it has absolutely no false negatives. You'll never get a successful
compilation if the compiler can't prove that a condition is true.
But it makes some code impossible to write:
#define compiler_assert(e) do \
{ \
[[gnu::error("")]] extern void fail_(void); \
\
if (!(e)) \
fail_(); \
} while (0)
void f(int* p) {
compiler_assert(p != nullptr);
}
Even with optimizations turned up to maximum, this will always be ill-formed.
The condition of "known at compile time" is weaker than the standard's concept of "constant expression", but not formally specified and probably impossible to specify in the abstract machine.
I've experimented with this kind of use of [[gnu::error]] for assertions in libstdc++, and it's not usable in general, because most code cannot require that all inputs are compile-time constants.