On Wed, 19 Jun 2024 at 07:12, Yexuan Xiao via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
>

Yes, and that's fine. If you want to throw an std::error_code instead of a
std::errc, then do that.



> 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.
>

You wouldn't be allowed to overload operator throw for std::errc anyway
though, because it's a type controlled by the standard library, so you
don't get to decide its API. So at most you could do this for
program-defined types like my::errc and acme::errc.

And it's unlikely the standard library would ever overload it for
std::errc, because that would be a breaking change for anybody who actually
does want to throw a std::errc (which is perfectly valid C++ today, even if
you say it's a mistake).