Hello Robin

Thank you for reviewing my P4021 proposal.

On 07/03/2026 07:06, Robin Savonen Söderholm via Std-Proposals wrote:
> Would it be possible, as a different angle of this idea, to have a profile that causes a compilation error on pre conditions that the compiler can't prove, which also has the implication that those asserts are removed from runtime?
>

May I clarify:

I think compile_assert fulfils this at present:

* Each pre condition fail stops the compile (no obj file produced)
* compile_assert is always removed from runtime. Never gets into compiled code
> I think that trying to combine this compile assert with contracts in some way has the added benefit that the compiler can evaluate it at call site, which should theoretically improve the performance of this feature with functions that exists in different TUs.
>
> // Robin

You're completely right, it's very useful to evaluate at call site.

Different TU also can work with LTO optimization. I have an example test_29
https://github.com/jonnygrant/compile_assert/blob/main/testsuite/test_29_lto1_a.c

Best regards
Jonathan


>
> On Sat, Mar 7, 2026, 07:25 Simon Schröder via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
>
>
> > On Mar 5, 2026, at 2:04 AM, Jonathan Grant via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
> >
> > I usually use for very straight-forward things, like array access index bounds checks, or nullptr.
>
> If this is the main application area, I really don’t see the advantage over contracts. In many cases the compiler can (could?) be able to prove that the contract is always fulfilled and eliminate the check when optimization is turned on. So, it works the same if it can be proven (no runtime performance overhead). Where contracts and compile_assert differ is in cases where it cannot be proven. Contracts will just leave the check in and compile_assert refuses to compile. Outside of embedded systems I expect programmers to prefer contracts: an occasional overhead doesn’t hurt too much and I’d rather have my software working with this little overhead than having to fight a checker. Standard library hardening has shown in large projects that usually the overhead of contracts is negligible.
>
> One advantage of contracts over your proposal are the pre and post conditions that are checked (or eliminated) on every call. This means that with contracts it is not up to the programmer to remember to sprinkle compile_assert everywhere. You might even remove a compile_assert because the compiler cannot prove it. In the context of memory safety this makes compile_assert a worse choice than contracts (for everyone who can pay the tiny overhead).
>
> On the other hand, this is a strong point to make compile_assert an option for contract enforcement. However, this means that we would need a way to skip proving to make our program compile. Maybe we can add an attribute [[no_contract_proof]] (I couldn’t quickly come up with a better name) to function calls where we don’t want a compile time check of the pre condition. Or we can have a contract_assume() that only makes assumptions for contract proving, but has no influence on optimizations like [[assume()]]. (Though the regular [[assume()]] can be used by contract proving as well.)
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>