I, for one, would love to see a global mutex taken on every throw.

In case it's not obvious, this is sarcasm.

Exceptions are already too slow, making them have global side effects is
the opposite of where we should be going.

On Thu, Feb 29, 2024, 13:01 David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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).
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>