On Mon, May 5, 2025 at 7:31 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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?

Within the context of the bad idea under discussion, that wouldn't
really work. After all, C functions are technically "noexcept" but
they aren't labeled as such, so such code would be unable to call
them. Furthermore, the committee's rules for when non-throwing
functions should be marked `noexcept` don't match with the needs of
the proposed feature.

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

That wouldn't work with the idea in question (which again, is a *bad*
idea). If `noexcept` functions fail to compile if they invoke a
non-`noexcept` function, you can't just wrap them, as the wrapper
would fall prey to the same problem. You need a way to pretend that a
non-`noexcept` function is `noexcept`.