Re: [boost] Outcome v2

12 Jul 2017

      On Tue, Jul 11, 2017 at 3:16 PM, Emil Dotchevski 
wrote:
...
On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost <
boost@lists.boost.org> 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 foo() noexcept;

outcome::result 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.

Requiring functions to always know what error types they may return is
reinventing exception specifications. Let's not resurrect that monster.