cool.
It seems that your writing is more convenient.



---- 回复的原邮件 ----
| 发件人 | Emanuel Spiridon via Std-Proposals<std-proposals_at_[hidden]> |
| 日期 | 2026年08月04日 20:36 |
| 收件人 | std-proposals_at_[hidden] |
| 抄送至 | Emanuel Spiridon<spiridonemanuel23_at_[hidden]> |
| 主题 | Re: [std-proposals] Class-level opt-in noexcept attribute (non-inheriting) |
What would you do in a case of a large class with many functions that has an equal amount of noexcept and otherwise default functions?


The amount of boilerplate wouldn't really change, you would just have multiple ways of tackling the same problem.


A better suggestion would be making class access-specifier labels be able to be noexcept. Somewhat like this:


```
class A
{
public noexcept:
    void foo();
    void bar();


public:
    void baz();
    void may_throw();


private noexcept:
    void helper();


private:
    int value;
};
```


This will allow you to cleanly separate functions with the noexcept property from the functions without it.




On Tue, Aug 4, 2026, 15:10 geguji60--- via Std-Proposals <std-proposals_at_[hidden]> wrote:



Hello all,


I’d like to propose a small, local extension to the core language:


a class-head noexcept-specifier, analogous to final or explicit .




Motivation


 noexcept is currently a per-function property. For many types—especially


value types, RAII guards, and low-level utility classes—every member function


can and should be noexcept . Today this must be repeated manually, which is


verbose, error-prone, and easily forgotten during refactoring.


A class-level specifier would make the intent clear and machine-checkable.






Semantics (intended)


The noexcept specifier applies only to member functions declared within the class-body.


It is non-inheriting and non-deductive.


An explicit noexcept on a member declaration overrides the class-level specifier.


Defaulted special members respect the class-level specifier.


The meaning is exactly as if noexcept(true) / noexcept(false) were written on each affected declaration.


The specifier does not affect:


base classes,


derived classes,


out-of-line definitions,


non-member functions,


friends.




​Relationship to existing features



Not noexcept(auto) (N4473): no deduction from function bodies.


Not [[noexcept]] : this is a specifier in the grammar, not an attribute.


Similar to final : applies locally to the class, not inherited, affects declarations within the class body.


Effect on language rules


 noexcept(expr) sees the same result as if the specifier were written manually.


Overload resolution, function pointer type, and mangling are unchanged in semantics—only the source location of the specifier differs.


No ABI impact beyond what manual noexcept already implies.




gauge WG feedback on the general direction.


Thanks,


geguj geguji60_at_[hidden]

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals