Hi Tony,

On 2026-03-10T16:07:29-0400, Tony V E wrote:
> Should the name be closer to
>
> optimizer_assert()

Indeed, that's the name I'm proposing in WG14.


Have a lovely night!
Alex

>
> Or something like that?
>
>
>
> Be seeing you,
> Tony
>
> On Sat., Mar. 7, 2026, 9:43 a.m. Alejandro Colomar via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
> > Hi Simon,
> >
> > On 2026-03-07T07:24:54+0100, Simon Schröder via Std-Proposals 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.
> >
> > You mean you prefer a run-time crash over a compile-time diagnostic?
> >
> > You don't need a hard error. A diagnostic that one could turn off would
> > be enough for safety. I've written a proposal for C, and I've specified
> > it so that there's only a mandatory diagnostic, and then compilation may
> > continue, if you wish.
> >
> >
> > Have a lovely day!
> > Alex
> >
> > > 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
> >
> > --
> > <https://www.alejandro-colomar.es>
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >

-- 
<https://www.alejandro-colomar.es>