Re: [boost] Outcome v2

Subject: Re: [boost] Outcome v2
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-13 01:26:23

On Wed, Jul 12, 2017 at 5:29 PM, Gavin Lambert via Boost <
boost_at_[hidden]> wrote:

> On 13/07/2017 11:48, Emil Dotchevski wrote:
>
>> then you have no choice but to do an error domain conversion.
>>>
>>
>> In case of Outcome, yes.
>>
>> In case of Noexcept, no, it has been designed to be able to propagate the
>> original error object.
>>
>
> That worries me a bit where code is using a generic type such as int for
> error codes but don't have the same meanings for the values.  It would be
> very easy to accidentally let one slip through without conversion so that
> it ends up representing the wrong error.
>

Agreed. I generally don't recommend returning int error codes with
Noexcept, for the same reason it is a bad idea to throw an int.

But this is a different issue. The problem when you have to go from
result<T,E1> to result<U,E2> is not that you could mess up the translation
from E1 to E2 (to your point, yes, you could), but that in general you
don't know what E1 is, and so there is no good way to design E2 capable to
represent all E1 failures efficiently.

And if you had a type that could transport more or less any unknown E2
efficiently, then you'd build an error handling library around that,
deleting the E template parameter, and you'd be left with result<T>. That
was Noexcept V1, but the fact that my solution to the problem pushed the
error object out into TLS left very little value in requiring a special
return type result<T>, so I deleted that too.