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::"