Re: [boost] Outcome v2

13 Jul 2017


      On Thu, Jul 13, 2017 at 2:16 AM, Andrzej Krzemienski via Boost <
boost@lists.boost.org> wrote:
...
2017-07-12 20:49 GMT+02:00 Emil Dotchevski via Boost <
boost@lists.boost.org>
:
...
On Wed, Jul 12, 2017 at 10:23 AM, Andrzej Krzemienski via Boost <
boost@lists.boost.org> wrote:
...
...
On Tue, Jul 11, 2017 at 3:16 PM, Emil Dotchevski <
emildotchevski@gmail.com
...
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.
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.