On Thu, May 12, 2022 at 6:26 AM Niall Douglas via SG14 <
sg14_at_[hidden]> wrote:

>
> 1. I'm not keen on allowing copy constructible for erased status codes
> because it adds very significant runtime overhead, which is why the
> present design specifically has the user explicitly opt into requesting
> a copy via clone(). This is because an erased status code needs to call
> a virtual function every time a copy is done, in order to have the
> erased implementation do the copy. Move-only erased status codes
> eliminate that overhead, as erasure is not available to status codes
> without bit copyable payload. Also, there will be payloads which are
> uncopyable, and that would mean copy construction would have to be able
> to throw.


I don't know much about the-proposed-std::error, and Niall's "make it
move-only" is probably reasonable. But the last word in this paragraph
surprises me. I thought the point of the-proposed-std::error was going to
be that it provides a *replacement* for the old "fail means throw an
exception" model. It seems upside-down that if an operation *completely
internal to the-proposed-std::error* fails, it would have any excuse at all
to signal that failure by throwing an exception!
Surely the result of the copy would just store
std::error::couldnt_copy_payload, or whatever, and keep trucking.

The std::filesystem API already experimented with the hybrid model of
"usually failure doesn't mean throw, except sometimes it does
[specifically, when it's std::bad_alloc]," and IMO the result did not
succeed in being comprehensible to ordinary programmers. Building that
hybrid model into the-proposed-std::error *mechanism itself* seems like it
would be an even worse idea.

my $.02,
–Arthur