On 19/02/2026 15:11, Jan Schultke via Std-Proposals wrote:
> I can't bring myself not to think of it as a "false positive". compile_assertis 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.

Hi Jan

Thank you for taking a look at this.

That is true. Some things are intractable, so they would fail a compile_assert() added by a programmer. So the choice could be:

A) Choose not to add a compile_assert() check.
B) If a programmer really wants sanity checking compile_assert(), they would need to refactor the code, perhaps putting a little part in a separate file. (eg the 'unsafe' part that is indexing into buffer sizes that are not known at compile time.
 
> 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.
>
>
You're right, if a compiler doesn't know sqrt(25) gives 5, it would fail that constraint. I keep most of my compile_assert(expr) pretty straightforward. Do you think I need some more tests? or better just to show use of compile_assert() in well known open source packages? I do find overflow risks. Compressed data uncompressing into a fixed sized buffer etc.

Compiler warnings aren't perfect. Sometimes gcc warns me a variable may be used uninitialized, even though I think it won't be. So I initialize it to a suitable value. I'm okay with that.

Thank you again for taking a look, let me know if any other thoughts how the proposal could be improved.

Regards
Jonathan