Im not about noexcept(auto), im about implicit noexcept autodetect if
noexcept specifier not exist on move constructor, move assign operator and
lambdas.

It already works for = default special member functions

вт, 10 июн. 2025 г. в 03:45, Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]>:

>
>
> 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.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>