[Development] Disavowing the Lakos Rule for Q_ASSERT

[Ville Voutilainen]

On Tue, 27 Aug 2024 at 05:18, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> On Monday 26 August 2024 15:35:11 GMT-7 Ville Voutilainen wrote:
> > >  a) turning precondition checks into runtime validations
> > >  b) using exceptions for the runtime validation
> > >  c) violating the precondition that caused the problem.
> >
> > Right. Preconditions are as-if in the function body. Both for
> > definition-side checks and for caller-client side checks.
> > Otherwise a noexcept isn't a noexcept, and nobody wants that.
>
> So an implementation could implement the verification of preconditions in the
> callee, which may need to throw exceptions to signify a violation, instead of
> duplicating it everywhere where the call is taken place. That makes sense...
> but I disagree. I don't want that.
>
> It should instead emit an extra helper function that gets merged by all
> callers if they desire. That way, the callee can assume all preconditions have
> been verified and need not spend cycles. And callers don't need to check
> conditions that the compiler can prove are already met.
>
> Maybe implementations will allow either or both verification modes.

Sure. The spec will need to allow for double-evaluation of
preconditions, so that if you happen to build
with both caller-client checks and definition checks, that's allowed.
Which is ruminated on in
https://open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3264r1.html


> I also urge you to expand on the case of std::vector::operator[]. Are you
> proposing that it a) become non-noexcept, b) have its UB not defined by the
> boundary of the precondition, or c) have a precondition that cannot be turned
> into an exception?

std::vector::operator[] is already non-noexcept. The implementations
don't mark it noexcept
because they have to, but because they can, as implementations are
allowed to strengthen noexcept-specs.