Re: [boost] Outcome v2

Subject: Re: [boost] Outcome v2
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-12 22:26:33

On Wed, Jul 12, 2017 at 11:49 AM, Emil Dotchevski <emildotchevski_at_[hidden]>
wrote:

> On Wed, Jul 12, 2017 at 10:23 AM, Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
>
>> > On Tue, Jul 11, 2017 at 3:16 PM, Emil Dotchevski <
>> emildotchevski_at_[hidden]
>> > >
>> > wrote:
>> >
>> > > On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost <
>> > > boost_at_[hidden]> wrote:
>> > >
>> > >> > Outcome does not solve the most important problem that needs
>> solving
>> > by
>> > >> an
>> > >> > error handling library.
>> > >>
>> > >> Does Expected?
>> > >>
>> > >
>> > > Nope, but the original outcome<T> was closer. I thought, perhaps it is
>> > > possible to make it able to transport arbitrary error types, and not
>> by
>> > > exception_ptr. My attempt at solving that problem lead me to TLS but
>> > maybe
>> > > there are other ways.
>> > >
>> >
>> > Allow me to clarify. Suppose I have a function foo which returns FILE *
>> on
>> > success, some EC1 on failure, and another function bar(), which calls
>> foo
>> > and returns an int on success, some EC2 on failure. I believe in terms
>> of
>> > Outcome this would be:
>> >
>> > outcome::result<FILE *,EC1> foo() noexcept;
>> >
>> > outcome::result<int,EC2> bar() noexcept {
>> >   if( auto r=foo() ) {
>> >     //no error, use r.value(), produce the int result or return EC2(x).
>> >   } else {
>> >     return ______;
>> >   }
>> > }
>> >
>> > What do you recommend in place of _____?
>> >
>> > Here is the same code in terms of Noexcept:
>> >
>> > FILE * foo() noexcept;
>> >
>> > int bar() noexcept {
>> >   if( FILE * r=foo() ) {
>> >     //no error, use r, produce the int result or return throw_(EC2(x)).
>> >   } else {
>> >     return throw_();
>> >   }
>> > }
>> >
>> > That is, with Noexcept, bar() would not care what error types propagate
>> out
>> > of foo because it can't handle any errors anyway. Whatever the error
>> is, it
>> > is simply passed to the caller.
>>
>> The default  EC type in outcome::result<> is std::error_code, and it is
>> possible to use only this type throughout entire program
>
>
> I didn't mean that you would design the program like this, the point is
> that you may not have control over the fact that foo returns EC1, and you
> still have to be able to write bar() (I should have made that clearer by
> using different namespaces.)
>
> In this comment you're echoing what Niall was saying in the documentation
> of the original Outcome, where he had several paragraphs attempting to
> convince the reader to stop using random error codes and _always_ use
> std::error_code, with technical phrases like "don't be anti-social" :)
>
> But that is not our reality, and it will never be our reality in C++
> because C++ programs do use C libraries, and because different C++
> libraries commonly use their own types for similar things. This is
> especially true for error codes.
>
>
>> given that these
>> errors are to be handled immediatly in the next layer, it should not be
>> that much of the problem.
>>
>
> In my example the error is not to be handled immediately in the next
> layer. I don't need an error handling library if the error is always
> handled "in the next layer".
>

To clarify the clarification of the clarification, I _am_ interested in
finding a way to express the equivalent of the Noexcept return throw_()
without using TLS, and I don't insist on it being a free function; for
example it would be sufficient if somehow I could just return r in case of
an error, as long as it works regardless of what error type r might
contain, and of course it should be reasonably efficient.