Yes, it’s designed for future types, and the mention of std::errc here is solely because it’s well-known from the standard library. I have no plans to add the overload for std::errc.
________________________________
From: Jonathan Wakely <cxx_at_[hidden]>
Sent: Wednesday, June 19, 2024 19:02
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Yexuan Xiao <bizwen_at_[hidden]>
Subject: Re: [std-proposals] operator throw



On Wed, 19 Jun 2024 at 07:12, Yexuan Xiao via Std-Proposals <std-proposals_at_[hidden]<mailto: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).