But I think that an added bonus to utilising profiles and contracts is that
if a library writer adds contracts to their functions, a user of that
library can opt-in for a compile assert that all preconditions are
satisfied without the library writer needing to write 'compile_asserts'
anywhere. And a user that maybe just want to quickly prototype something
using the same library can let a default runtime handler take care of any
contract violations.
Further than that, I can imagine that we may even use the postconditions as
a way to improve the accuracy (and thus, reduce false positives) of the
compile time checks.

Best,
Robin

On Wed, Mar 11, 2026, 04:26 Jonathan Grant via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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>
> >
> >
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>