Date: Mon, 05 May 2025 16:31:41 -0700
On Monday, 5 May 2025 07:02:31 Pacific Daylight Time Jason McKesson via Std-
Proposals wrote:
> The context of this conversation is such that `noexcept` has a
> (completely) different meaning than it currently has. The OP wants the
> compiler to statically verify that no exception throwing happens
> *within* a `noexcept` function, not merely that the function itself
> cannot allow an exception to pass through it. The point of the cast is
> to take a function that isn't marked `noexcept` but will not throw and
> tell the compiler that it's OK to call it in a `noexcept` function
> (because the OP wants calls to non-noexcept functions to give an
> error).
And why is this a good idea? Why can't we consider it a QoI of the libraries
in question that they failed to mark their noexcept functions as noexcept?
If you really need this, just wrap them in an noexcept IILE. If they don't
throw, this has cost you a few bytes in the exception handling table. If they
do throw, you'll abort at runtime.
Proposals wrote:
> The context of this conversation is such that `noexcept` has a
> (completely) different meaning than it currently has. The OP wants the
> compiler to statically verify that no exception throwing happens
> *within* a `noexcept` function, not merely that the function itself
> cannot allow an exception to pass through it. The point of the cast is
> to take a function that isn't marked `noexcept` but will not throw and
> tell the compiler that it's OK to call it in a `noexcept` function
> (because the OP wants calls to non-noexcept functions to give an
> error).
And why is this a good idea? Why can't we consider it a QoI of the libraries
in question that they failed to mark their noexcept functions as noexcept?
If you really need this, just wrap them in an noexcept IILE. If they don't
throw, this has cost you a few bytes in the exception handling table. If they
do throw, you'll abort at runtime.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2025-05-05 23:31:48