Hi, what you basically seem to want is either a) variants of those standard library functions. Those should check for their requirements (is this always possible?) and terminate instead of throwing an exception or exhibiting UB _and_ also be marked noexcept; or   b) a variant function signature, which is marked noexcept, but with no checks, so anything (UB) can happen with unfulfilled preconditions, but no exception is thrown for fulfilled preconditions. The caller is responsible.     -----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