On Mon, 9 Jun 2025, 23:12 Andrey Semashev via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On 10 Jun 2025 00:45, Ville Voutilainen via Std-Proposals wrote:
> > On Tue, 10 Jun 2025 at 00:40, Thiago Macieira via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >>
> >> On Monday, 9 June 2025 17:57:41 Brasilia Standard Time Andrey Semashev
> via
> >> Std-Proposals 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.
>
> 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).
>

I don't think it's useful for the spec.

The standard library spec could only use noexcept(auto) when a function is
entirely specified as code. Anything specified as prose like "initializes
foo with a copy of bar" couldn't use it, because what is the compiler
deciding the noexcept from? Words?

Currently when the standard says the noexcept specifier is e.g.
is_nothrow_move_constructible_v<T> that tells you the function can't do
anything else that might throw, such as allocate memory. If you change it
to noexcept(auto) you remove that guarantee. Now you need other words to
say it doesn't do anything else that can throw.

And if you remove the Throws: paragraph, how do you know what exceptions it
can throw? noexcept(auto) tells you it might or might not throw, but it
doesn't tell you what it throws. A function could catch all exceptions and
then then into std::system_error, but saying it throws what the constructor
of T throws guarantees it won't do that. Remove those paragraphs, and you
lose that guarantee too.