Hi Jonathan,

I can't address every point, but the point I was making is that I
*don't* want to have to use noexcept everywhere, but as it stands now
you *have* to do that if you so much as have 1 function you want to be
noexcept (Such as operator new for instance) but don't want the
handlers in the final binary for certain reasons. As in, if you have 1
function that needs to be throw() which calls other functions, those
other functions and the functions they in turn call have to be throw()
as well, which gets tedious to do really quickly.

You're right that it isn't impossible to call C library functions from
noexcept code without the handlers, I had neglected to mention the
"Cast to throw() function pointer" trick*. But that too gets annoying
when you have to do it at every call to the C library unfortunately.

best regards,
Julian

*For anyone wondering what the trick I'm referring to is, it's this:

void method() throw() {
    void * (*mallocPtr) (size_t) = [] (size_t size) -> void * { return
::malloc(size); }; // Save the function pointer
    void *ptr = reinterpret_cast<void * (*) (size_t)
throw()>(mallocPtr)(1); // Without this step, the dreaded handlers
will be silently inserted into the final binary since method is
throw() (In practice, on most platforms)
    // Code to free the malloc memory goes here
}

On Sun, Apr 27, 2025 at 10:22 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
>
> On Sun, 27 Apr 2025, 14:51 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.
>
>
>
> Or stop using it unnecessarily everywhere, so the code doesn't need handlers in every function.
>
>
>
>> If you don't? Yay, free invisible exception handlers (That I don't want) in the final assembly!
>
>
> That depends on the compiler, the handlers don't need to be in the function at all, and don't need to add code to every level of the stack.
>
>
>
>> It's just not
>> practical to have to do that, in fact, on some implementations the C
>> standard library functions aren't noexcept like the standard says they
>> should be
>
>
> Does it say that?
>
>
>> (Such as with the mingw-w64-headers), so it is physically
>> impossible to avoid the exception handlers if you want your program to
>> do anything useful at all (Because ultimately you have to call C
>> functions sooner or later, and you know what happens if you call a
>> potentially throwing function from a throw() one).
>
>
> Physically impossible is a bit strong. You can wrap the C library calls in noexcept functions compiled with -fno-exceptions, or mark exceptional paths as unreachable.
>
>
>>
>> I do want to say I'm excited for
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3166r0.html
>> but it seems to also not fully address this issue with noexcept
>> unfortunately. I really wish C++ functions were throw() by default
>> sometimes like in other languages so we didn't have to deal with this
>> mess, although that will never happen due to breaking existing code by
>> this point. At this rate, I'd much rather deal with exceptions that
>> are brittle and harder to use like Java checked exceptions than with
>> an exception system that silently inserts extra code into your
>> programs if you don't obsessively mark everything noexcept.
>
>
>
> I think the problem is being overstated.
>
>
>> As it
>> stands, the former would annoy developers greatly, the latter makes
>> everyone slap -fno-exceptions onto the codebase and fragments the C++
>> world into nonconforming dialects, because it is a problem if you work
>> on a very low level codebase where every tiny change in the compiled
>> assembly matters greatly, such as the JVM.
>>
>> Whew, that was quite a rant, but it was something that I find pretty
>> annoying. Hope you all don't mind.
>>
>> best regards,
>> Julian
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals