On Tue, 10 Jun 2025 at 01:12, Andrey Semashev via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> >>> Adding support for noexcept(auto) would not remove noexcept(bool), so
> >>> one can continue marking functions noexcept(bool) as they did before.
> >>> But the use case where one wants to just forward noexcept-ness is rather
> >>> common and would be served by noexcept(auto).
> >>
> >> Indeed it is. But noexcept(auto) has been discussed before and any new
> >> proposal about it should address the concerns raised before. I don't see any
> >> of that here.
> >>
> >> The difference here appears to be to limit it to lambdas and the move
> >> constructor. IMO, that's going to make the proposal even less palatable.
> >
> > When I was writing papers related to noexcept(auto), what I did not
> > find is evidence supporting
> > the suggestion that it is "rather common", in the grand scheme of things.
>
> Not sure what counts as the grand scheme of things, but I wish I had
> noexcept(auto) almost every time I have to write a proxy object (e.g. as
> a recent example, a proxy returned from operator[] for an iterator) or
> an algorithm that operates on user's objects. Pretty much every time you
> write noexcept(noexcept(...)), noexcept(auto) is probably desirable, and
> also a great deal of cases where you write
> noexcept(is_nothrow_xyz<T>::value) as well.

The grand scheme of things is how many users write such proxy objects,
and how often.

> Consider how many times the C++ standard says noexcept(see below) in the
> synopsis only to way "Throws: Any exception thrown by this or that
> operation of T" in the description. Most if not all these cases could be
> succinctly replaced with noexcept(auto).

Yes, I'm aware of that. I don't find that a compelling rationale for
adding a new language feature.