In "pre-contracts C++" the pre-conditions are not an explicit part of the language. In "contracts C++" the noexcept could be refined to not apply to contract violations of the caller. (or could this also be done in pre-contracts C++?)   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 15.09.2026 14:01 Betreff:Re: [std-proposals] noexcept(static) An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Mon, Sep 7, 2026 at 1:59 PM Thiago Macieira wrote: > > That's not what I meant. I want to go back to first principles of what I intended with 'noexcept(static)'. Most basically, where we have code like this:    void Func(void)    {        a();        b();        c();    } I want it to be compiled as follows:    void Func(void)    {        static_assert( noexcept( a() ) );        a();        static_assert( noexcept( b() ) );        b();        static_assert( noexcept( c() ) );        c();    } What complicates this significantly, as you mentioned, is the Lakos rule -- i.e. "The throwing of an exception is an acceptable form of undefined behaviour". But given the Lakos rule, should "std::sqrt" be defined as follows?    double sqrt(double) noexceptLakos; I'm saying, should we have a new marker/identifier/keyword/annotation/attribute to indicate that a function won't throw so long as you don't invoke UB? Or should 'noexcept(static)' be secretly aware of which functions are Lakos (such as 'vector::operator[]')? This wouldn't be complicated as I could ask Claude to scour through the PDF of the Standard and pick out all Lakos functions and methods. . . which I think would blanketly include anything declared in the C headers, e.g. <math.h> or <cmath>, and then just a few more things such as vector::operator[]. I was also toying with the idea of having another namespace, e.g. std::Lakos, which would contain std::Lakos::sqrt -- but the only problem here is that "std::vector" and "std::Lakos::vector" would be different types -- unless we were to create yet another rule that types defined inside "std::Lakos::" can be safely aliased to types inside "std::" -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals