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@lists.isocpp.org>
Gesendet: Di 15.09.2026 14:01
Betreff: Re: [std-proposals] noexcept(static)
An: std-proposals@lists.isocpp.org;
CC: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>;
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals