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?

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

On Sat, Mar 7, 2026, 07:25 Simon Schröder via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> > On Mar 5, 2026, at 2:04 AM, Jonathan Grant via Std-Proposals <
> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>