On 9 Jun 2025 21:43, Thiago Macieira via Std-Proposals wrote:
> On Monday, 9 June 2025 14:36:50 Brasilia Standard Time Andrey Semashev via
> Std-Proposals wrote:
>> On 9 Jun 2025 18:20, Andre Kostur via Std-Proposals wrote:
>>> Food for thought: there may be a silent performance degradation if
>>> such a constructor were to "accidentally" get a noexcept(false)
>>> function call somewhere. Or some member variable (or
>>> member-of-a-member, etc) loses its noexcept(true) status.
>>
>> Losing performance would be better than silently introducing a code path
>> that ends with std::terminate(). Also, you can test that your function
>> marked as noexcept(auto) remains noexcept(true) in tests, but you can't
>> test that your function marked as noexcept(true) doesn't actually call
>> std::terminate if something within it becomes potentially throwing.
>
> On the other hand, you may be calling noexcept(false) functions in your code
> but know that they can't throw (almost any C function, for example). In this
> case, you must keep marking your function noexcept.

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