On 12/05/2022 16:56, Arthur O'Dwyer wrote:
> On Thu, May 12, 2022 at 6:26 AM Niall Douglas via SG14
> <sg14_at_[hidden] <mailto: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.

It's up to the status code domain's implementer to implement
do_erased_copy(), and they can choose to do anything they want to
indicate that clone() has failed. If they want to return a zombied
status code, absolutely fine.

Of the status code domains proposed for standardisation, to my knowledge
clone() can throw for this only:

- status_code_ptr_domain (a status code which points to another status
code), bad_alloc can get thrown, so may any exception throws by the copy
constructor of the payload of the pointed to status code.

I think that reasonable, given we can say nothing about the custom
status codes people will define.

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

100% agreement that error_code overloads of filesystem also throwing is
an abomination and a most unfortunate mistake by WG21 in my opinion.

Rest assured I would fight to my utmost to never do the same in any
paper with my name on it.

Niall