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@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