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?