Date: Thu, 5 Mar 2026 00:43:51 +0000
On 20/02/2026 14:52, Jan Schultke via Std-Proposals wrote:
>
> __
>
> Can this feature proposal be lifted from a best-effort base to be reproducible?
>
> Something like preconditions contracts, which have to be provably be true at compile-time.
>
> Can there be hints to guide the compiler to a deterministic proof?
>
>
> We could at least specify that if the condition is a constant expression, the assertion behaves correctly instead of being best-effort. Anything past that would seemingly require us to standardize a bunch of control flow and data flow analysis, and I don't think anyone wants to do that just for the sake of this assertion.
>
> I think the target audience for this feature is aware that it's playing Russian Roulette with compiler errors, and should probably never be used in large production code bases that compile with more than one compiler, or at least not with default build flags. Making the feature even slightly more predictable comes with great effort, and I don't think it would meaningfully impact who would or wouldn't use the feature.
>
>
You make very good points Jan. It is a lot of effort to get the compile_assert in (of course requires a programmer to enter them all in risky places), although the pay off is when they find an issue. Most of the time I check seeming straightforward things like an index into a fixed sized buffer, which seems to not change by the optimizer so far.
BTW. The linux kernel has the same kind of macro to stop a compile I just found out about.
Sometimes I only add compile_assert to code I am reviewing for issues to try find the issue. I can leave the compile_assert in (but turned off). Latest revision has a way to turn it on, and without that compile_assert is off in all builds.
Latest revision is here:
https://isocpp.org/files/papers/P4021R1.pdf
Thank you again for your comments.
Jonathan
>
> __
>
> Can this feature proposal be lifted from a best-effort base to be reproducible?
>
> Something like preconditions contracts, which have to be provably be true at compile-time.
>
> Can there be hints to guide the compiler to a deterministic proof?
>
>
> We could at least specify that if the condition is a constant expression, the assertion behaves correctly instead of being best-effort. Anything past that would seemingly require us to standardize a bunch of control flow and data flow analysis, and I don't think anyone wants to do that just for the sake of this assertion.
>
> I think the target audience for this feature is aware that it's playing Russian Roulette with compiler errors, and should probably never be used in large production code bases that compile with more than one compiler, or at least not with default build flags. Making the feature even slightly more predictable comes with great effort, and I don't think it would meaningfully impact who would or wouldn't use the feature.
>
>
You make very good points Jan. It is a lot of effort to get the compile_assert in (of course requires a programmer to enter them all in risky places), although the pay off is when they find an issue. Most of the time I check seeming straightforward things like an index into a fixed sized buffer, which seems to not change by the optimizer so far.
BTW. The linux kernel has the same kind of macro to stop a compile I just found out about.
Sometimes I only add compile_assert to code I am reviewing for issues to try find the issue. I can leave the compile_assert in (but turned off). Latest revision has a way to turn it on, and without that compile_assert is off in all builds.
Latest revision is here:
https://isocpp.org/files/papers/P4021R1.pdf
Thank you again for your comments.
Jonathan
Received on 2026-03-05 00:43:59