On 10 Jun 2025 01:16, Ville Voutilainen wrote:
> 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.

I realize that the Standard Committee resources are limited, but I also
don't find this argument convincing. You could argue the same way e.g.
about coroutines or any other niche feature of the language, which was
arguably more expensive to standardize and implement, yet here we are.

Clearly, proxy objects were written before and continue to be written.
And proxy objects are not the only use case, as new classes appear in
the C++ standard library itself, where the aforementioned noexcept(see
below) is being written. Let alone the code outside the standard library.

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

Note that it's not just the standard library itself that could benefit
from having this feature. The standard library is an indication of a
missing feature that would be widely useful.