Re: [boost] Outcome v2

Subject: Re: [boost] Outcome v2
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-13 18:22:58

On Thu, Jul 13, 2017 at 2:16 AM, Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> 2017-07-12 20:49 GMT+02:00 Emil Dotchevski via Boost <
> boost_at_[hidden]>
> :
>
> > 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.)
> >
>
> So, you are saying that one can construct a programming problem that
> Outcome library will not be able to solve.

No, what I am saying is stronger: 1) the ability to transport arbitrary
error types is needed, and this is reflected in the current Outcome design
by the addition of the extra template parameters; but 2) this approach
suffers from the same problems exception specifications do.