cool.
It seems that your writing is more convenient.


---- 回复的原邮件 ----
发件人 Emanuel Spiridon via Std-Proposals<std-proposals@lists.isocpp.org>
日期 2026年08月04日 20:36
收件人 std-proposals@lists.isocpp.org
抄送至 Emanuel Spiridon<spiridonemanuel23@gmail.com>
主题 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@lists.isocpp.org> 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,

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals