Error codes are always not the actual objects thrown as exceptions. Therefore, it usually requires an explicit conversion of the error code when throwing it. I believe I have already demonstrated this issue in my initial email. The operand of co_await is usually not an awaiter, so a class that implements the operator co_await will become awaitable, allowing it to be used as an operand for co_await. While throw allows operands of any type, co_await does not. However, we don’t want error codes to be thrown directly, such as std::errc, as this is typically a mistake.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, June 19, 2024 11:44
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jason McKesson <jmckesson_at_[hidden]>
Subject: Re: [std-proposals] operator throw

On Tue, Jun 18, 2024 at 2:31 PM Yexuan Xiao via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.

His point still stands: the existence of a new operator overload for a
new operator does not justify the creation of a new operator overload
for an *old* operator.

However, if you want to try to equate these, then an important
question needs to be raised: why does `operator co_await` exist? This
functionality exists because some type might be able to support being
awaitable, but the authors of that type didn't implement proper C++
coroutine support. As such, you can invisibly inject a layer between
code that wants to await on that type and the potentially-awaitable
type.

Note that in this thinking, the type in question is not itself
awaitable. This means that `co_await non_awaitable` would be a compile
error without `operator co_await`. Now, this doesn't stop you from
injecting `operator co_await` overloads into a type that is awaitable.
But the feature's main purpose is to turn a non-awaitable into an
awaitable.

Any type which is copyable is *throwable*. So the purpose of this
feature is not to turn a non-throwable object into a throwable. It's
to turn a throwing expression into a *different* throwing expression.
The user said to throw X, and you said "no, throw Y instead".

Why is this a thing C++ needs?
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]pp.org
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=05%7C02%7C%7C4df446f007de45f13efb08dc901237c9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638543655145562612%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=086jOP4PAOczv0b%2B9pE6CBrJAMzz%2Bic6fuHOUIJ5Qeg%3D&reserved=0<https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>