Re: [boost] Outcome v2

12 Jul 2017


      On Wed, Jul 12, 2017 at 11:49 AM, Emil Dotchevski 
wrote:
...
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.)
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.