Member methods are still modified by noexcept, which is redundant, but allowed.



---- Replied Message ----
| From | Robert Baumgartner via Std-Proposals<std-proposals_at_[hidden]> |
| Date | 08/04/2026 20:30 |
| To | std-proposals_at_[hidden] |
| Cc | Robert Baumgartner<baumgar.robert_at_[hidden]> |
| Subject | Re: [std-proposals] Std-Proposals Digest, Vol 89, Issue 1 |
verbose, error-prone, and easily forgotten during refactoring. <- how is it error prone and easily forgotten during refactoring? A forgotten noexcept will be flagged by the compiler, won’t it?

> An explicit noexcept on a member declaration overrides the class-level specifier. <- why would you want to override what already has been declared? Wouldn’t you want rather a not_noexpect instead to clear the default?




> On Aug 4, 2026, at 14:10, std-proposals-request_at_[hidden] wrote:
>
> Send Std-Proposals mailing list submissions to
> std-proposals_at_[hidden]g
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> or, via email, send a message with subject or body 'help' to
> std-proposals-request_at_[hidden]cpp.org
>
> You can reach the person managing the list at
> std-proposals-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Std-Proposals digest..."
>
>
> Today's Topics:
>
> 1. Class-level opt-in noexcept attribute (non-inheriting)
> (geguji60_at_[hidden])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 4 Aug 2026 20:10:34 +0800 (GMT+08:00)
> From: "geguji60_at_[hidden]" <geguji60_at_[hidden]>
> To: std-proposals <std-proposals_at_lists.isocpp.org>
> Subject: [std-proposals] Class-level opt-in noexcept attribute
> (non-inheriting)
> Message-ID: <70f66ca6.ba461.19fccaec86d.Coremail.geguji60_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> 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]
> -------------- next part --------------
> HTML attachment scrubbed and removed
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Screenshot_2026_0804_200815.png
> Type: image/png
> Size: 67419 bytes
> Desc: not available
> URL: <https://lists.isocpp.org/std-proposals/attachments/20260804/8ffd5b4c/attachment.png>
>
> ------------------------------
>
> Subject: Digest Footer
>
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> ------------------------------
>
> End of Std-Proposals Digest, Vol 89, Issue 1
> ********************************************

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