On Tue, 27 Aug 2024 at 05:18, Thiago Macieira <thiago.macie...@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. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
