Boost logo

Boost :

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-02-02 09:19:15

> In contrast, Boost.Outcome is intended for usage in these rare cases were
> "forward up and abort" is not the thing you would like to do most of the
> time. Its goal is not to handle failures anywhere, but to solve a specific
> problem in specific places. I believe that the criticism of Boost.Outcome
> should be in this context of places where "forward up and abort" is not
> what you typically need to do.

And this really drives to heart of what I don't get about your arguments
Emil. Outcome is really an abstraction layer for setting per-namespace
rules for when to throw exceptions. Exception throwing is absolutely at
the heart of Outcome. That's why Outcome != Expected, and why it ICEs
older compilers, and why C++ 14 is needed.

Let me give you an example literally from what I was doing last night. I
just this week finally persuaded OS X to compile AFIO, and amazingly the
test suite passed as well as on Linux except for the async i/o test
which was failing.

>From the build log on Travis, I could immediately see that the cause was
a "resource temporarily unavailable" failure. An `io_result<>` was being
constructed with that failure, returned to the i/o completion handler
which in turn type erased it into an exception_ptr, put that into the
future for the completion handler, and finally at the end of the test
all accumulated failures were rethrown out out the futures for all the
async i/o.

Outcome behaved exactly as AFIO told it to behave: expected errors were
handled locally with an unmeasurably low overhead, unexpected errors
were type erased into an exception_ptr and pushed up the call stack.

Eventually after a fair bit of head scratching I discovered that OS X's
implementation of `aio_select()` does not do what its man page says it
does, so last night I committed a workaround and now async i/o works on
OS X, so -3 failures at yay!

The point I'm making here is that exception throws are what Outcome
does. You're basically arguing against the premise of this library on
ideological grounds, yet the library is fulfilling all of the rationales
you have made on why exception throws are the right approach. Outcome is
ticking all your boxes. Outcome is all about throwing exceptions.

Will you consider now changing your peer review vote?


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at