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).