Regardless of the syntax: In your example  - you want to distinguish between two modes: hardened and unhardened  - you want to guarantee that in both modes, your Monkey() function is noexcept   -> if your index is valid, no exception is thrown in any mode -> if your index is invalid, anything/UB may happen (narrow contract);    * certain implementations may deterministically throw an exception in those cases (those are probably the ones you call hardened)    - as your Monkey() function is noexcept, those hardened implementations terminate with an invalid index  - unhardened implementations lead to UB, so an exception may be thrown, but anything else may happen   "value_type &vector::operator[](size_t) noexcept_if_hardened(false) noexcept_if_unhardened(true);" What advantage does the "noexcept_if_unhardened(true)" part have?  - if you fulfill the narrow contract, no exception happens  -> that is also true for the hardened variant   That is, why there is the Lakos rule; to use one noexcept specification for both - hardened and unhardened - implementations   Somebody (couldn't find the specific post) recently said in this thread that for all functions throwing, because of the caller (compared to outside effects), the caller can narrow the contract further and avoid exceptions.   E.g. you have a file open function that throws on file not found. Then you get check first, whether the file exists and avoid the exception. Now you say that leads to a race condition. Another process could delete the file in between. Then write a wrapper that is noexcept. Then the program terminates in those cases or just declare the caller as noexcept. You want tooling support that no exception, no termination, no unhandled error remains in your program? -> Put a try catch around your main (and around each thread) to catch any exception.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 17.09.2026 12:36 Betreff:Re: [std-proposals] noexcept(static) An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;  'sqrt' is a bad example because it has a wide contract -- you're allowed to give it a negative number without inducing UB.  Let's talk about 'std::vector::operator[]' instead. If you give it an invalid index, you get UB. Because of the Lakos rule, it's marked 'noexcept(false)'.  Consider if we write this:      int &Monkey( vector<int> &v, size_t const n ) noexcept(static)     {         return v[n];     }  Basically I want this to be compiled as follows:      int &Monkey( vector<int> &v, size_t const n ) noexcept     {         static_assert( noexcept( v[n] ) );         return v[n];     }  The above will unfortunately fail to compile. So I think what we want is something like:      int &Monkey( vector<int> &v, size_t const n ) noexcept     {         static_assert( noexcept_if_unhardened( v[n] ) );         return v[n];     }  So then maybe we should have:      value_type &vector::operator[](size_t) noexcept_if_hardened(false) noexcept_if_unhardened(true);  Maybe.... ? Just mulling through a rumination of ideas here . . .          -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals