Date: Sun, 27 Apr 2025 10:20:42 -0400
On Sun, Apr 27, 2025 at 9:51 AM Julian Waters via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> I do agree noexcept has gotten a bit problematic, though I have no
> opinion on the proposal presented here. I do want to grab this
> opportunity to say that I find it pretty ridiculous that to reap the
> benefits of noexcept I have to mark the entire call chain all the way
> down noexcept though. If you don't? Yay, free invisible exception
> handlers (That I don't want) in the final assembly!
`noexcept` wasn't created to turn off "invisible exception handler"
generation. That's not its job, so it's not reasonable to try to make
it do something it wasn't meant to do.
The main point of `noexcept` was to be able to indicate *to the
caller* that the function won't emit in a way that static detection
tools (SFINAE) could detect and alter their code in response to. It
does not mean that a function throwing inside the function is invalid;
merely that it will not *emit* an exception.
<std-proposals_at_[hidden]> wrote:
>
> I do agree noexcept has gotten a bit problematic, though I have no
> opinion on the proposal presented here. I do want to grab this
> opportunity to say that I find it pretty ridiculous that to reap the
> benefits of noexcept I have to mark the entire call chain all the way
> down noexcept though. If you don't? Yay, free invisible exception
> handlers (That I don't want) in the final assembly!
`noexcept` wasn't created to turn off "invisible exception handler"
generation. That's not its job, so it's not reasonable to try to make
it do something it wasn't meant to do.
The main point of `noexcept` was to be able to indicate *to the
caller* that the function won't emit in a way that static detection
tools (SFINAE) could detect and alter their code in response to. It
does not mean that a function throwing inside the function is invalid;
merely that it will not *emit* an exception.
Received on 2025-04-27 14:20:54