The operator co_await and my idea address problems similar to those solved by user-defined literals, which simplify the construction of objects in specific contexts. No matter how you look at it, co_await is a very useful feature that is widely used.
________________________________
From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Sent: Wednesday, June 19, 2024 1:52
To: std-proposals_at_[hidden]ocpp.org <std-proposals_at_[hidden]>
Cc: Yexuan Xiao <bizwen_at_[hidden]>
Subject: Re: [std-proposals] operator throw

On Tue, Jun 18, 2024 at 1:02 PM Yexuan Xiao via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Hello everyone,
I’ve recently come up with a new idea and I’m looking for some feedback and opinions.

Currently, when using exceptions derived from std::exception and the status_code from P1028, it’s common to need to convert error values into exception objects. [...] C++ currently lacks a best practice for converting error codes into exception objects.

The two example approaches you gave were:
    std::error_code ec;
    throw std::system_error(ec); // (1)
    my::throw_system_error(ec); // (2); calls `void throw_system_error(std::error_code ec) { throw std::system_error(ec); }`

These both seem totally fine approaches. Neither of them is too verbose, and they clearly show the reader what's happening.
In fact, (2) is just (1) with the offending code factored out into a function; that's a good kind of refactoring that we want to continue to permit.

Therefore, I propose adding user-defined operator throw overload to implement automatic conversion from error codes to exception objects.

But why, though? I don't see that you've presented any problem that needs solving.
In fact, it seems to me that you're taking a non-problem (that if you want to convert X to Y and then throw Y, you write that) and making it into a problem (that it becomes impossible to throw X from generic code because there's no way to ensure that the author of X hasn't done something dumb in their `operator throw` implementation).

This idea is inspired by the existing operator co_await in C++, which facilitates the construction of awaiters for us.

My understanding is that `operator co_await` solves an actual problem (although off the top of my head I don't know what it is).
Its existence should not be taken as license to invent an `operator foo` for every named operator in C++. We don't need `operator throw`, `operator sizeof`, etc. (In hindsight, C++98's class-specific `operator new` and `operator delete` were mistakes too.)

Additionally, F. v.S. pointed out that this design has an extra side effect: if operator throw is overloaded as a member function, then the class can never be the actual type of an exception. Based on this, by avoiding defining operator throw(), or by adding =delete to it, can prevent objects of that class from being thrown as exception objects.

That's a bug, not a feature.
There is no idea here worth pursuing.

–Arthur