On 29/02/2024 12:10, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Thu, Feb 29, 2024 at 10:53 AM Jan Schultke wrote:
>>
>> I agree with Jonathan; this does not belong in the standard. For
>> starters, it makes optimizations impossible such as eliminating:
>>
>>> try {
>>> throw 0;
>>> } catch (...) {}
>
>
> I wasn't aware of any compilers doing this. Nor have I ever seen any
> real code that looks like this.
>
>
>> While compilers aren't very good at eliminating unnecessary try/catch,
>
>
> Compiler vendors probably have bigger fish to fry, because there
> aren't many programmers out there writing redundant try-catch's
> (especially in a context where performance is critical).

Do you understand how optimisations like this work? They are not just
for people who write redundant code - they are for people that write
normal code that, after inlining, constant propagation, IPAs, LTO, and
all sorts of other things, boil down to redundant code. Someone writes
a normal, practical try/catch block, calling functions from somewhere
else, but if the compiler is able to figure out that the code doesn't
ever throw an exception as it is called, it could eliminate the
exception handling.

Compilers do all sorts of similar optimisations. Maybe they don't do
this one yet, but I'm sure they will.

>
>
>> yet they should be allowed to do it. If you make it so that throwing
>> inevitably calls a global handler, this optimization becomes entirely
>> impossible, since any throw might have observable side effects.
>>
>> I'm also confident that given enough time (perhaps not C++26, but
>> eventually) constexpr exception handling will be a thing. It's unclear
>> how that would work when there is global mutable state in the form of
>> a throw handler. Global mutable state doesn't really exist in constant
>> expressions.
>
>
> Well we haven't got constexpr/consteval exception handling yet, so for
> the timebeing I'll put this feature forward. I'm reaching here . . .
> but if we're gonna have constexpr exception handling then maybe have
> constexpr 'throw handlers' as well.
>

The point is that if someone thoughtlessly adds a global handler here to
the standard, you cannot then have constexpr exception handling in the
future. Choices made today limit future possibilities, and should not
be taken lightly.

>
>> It's irrelevant how quickly you could hack together something that
>> works in a specific implementation.
>
>
> If we are to consider how much hassle it would be for compiler vendors
> to implement a new feature, then I think it's good to point out that
> one working implementation only took an hour to code in once source
> file on GodBolt

No. A feature might be added to the standard if it saves (for example)
10,000 developers from doing an extra 20 hours work each. That's
200,000 person-hours. The feature will take 2000 person-hours for
proposals, discussions, talks at conferences, updating the standard, and
documenting it in essential resources like cppreference.com. It is
almost totally and completely irrelevant whether implementation takes 1
hour or 100 hours in a compiler.

>
>
>> This doesn't belong in the C++ standard.
>
>
> The only argument I can see here against it being in the Standard is
> that the compiler won't be able to optimise away no-op try-catch
> blocks.

That is because you don't understand how the standardisation process
works. And you are unable to view the world beyond your own little bits
of code - you have no consideration for how your ideas may affect anyone
else, their existing code, or future code. Oh, and you also don't read
posts here when people tell you why something is inappropriate for
including in the standard - I have seen several arguments against it
here, and can think of several more (even though I can also see certain
arguments /for/ it).