But then in effect it would be  > - No code to catch, that is the point. UB! the programmer overrides the specification of the called function. No code should be emitted to check for/catch exceptions. If an exception is thrown nevertheless inside the noexcept_casted function, then it would be UB?     -----Ursprüngliche Nachricht----- Von:Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 05.05.2025 16:03 Betreff:Re: [std-proposals] noexcept has gotten a bit hairy -- I want a compiler error An:std-proposals_at_[hidden]; CC:Jason McKesson <jmckesson_at_[hidden]>; On Sun, May 4, 2025 at 2:45 PM Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote: > >  - it works without check. The exception just wanders to the next level. At the same time we can be noexcept. That is fine. 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). Now yes, this is a problem created only by the OP's insistence on changing the fundamental meaning of keywords, but that is the core context of this conversation. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals