[boost] [outcome] Requesting pre-review of Boost.Outcome tutorial

Subject: [boost] [outcome] Requesting pre-review of Boost.Outcome tutorial
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2016-11-20 02:04:48

On Fri, Nov 11, 2016 at 8:27 PM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> Dear Boost,
>
> I am hoping to bring Boost.Outcome, a C++ 14 library providing a
> factory and family of policy driven lightweight monadic
> value-or-error transports, into the Boost peer review queue by March
> 2017 followed shortly thereafter by an ACCU talk in April if my talk
> proposal passes their programme committee. To that end, I've written
> an explanation and a sort of tutorial explaining the history and
> purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd
> greatly appreciate if people could tell me:
>
> 1. Does it make sense?
>

Yes, the explanation is useful and does make sense.

>
> 2. Do you think you could use Outcome in your own code after reading
> it?
>
> 3. Do you think you would want to use Outcome in your own code after
> reading it?
>

I'm already using something similar in my oglplus2 OpenGL wrapper and some
other projects and I really like the technique. IMO the C++ community would
benefit from having something like this in Boost.

In my implementation the outcome is a pair of the "real" result and an
"error info" which can be more elaborate than an error code + a policy
which by default throws an exception from the error info when the outcome
is destroyed. The function caller can explicitly cancel the throwing and
just examine the error information. All functions returning outcome can be
noexcept.

>
> 4. Are there any missing parts which are showstoppers?
>

I didn't try to use your implementation, but I don't see anything obvious.
But a shorter initial tutorial would be helpful.

>
>
> My thanks in advance. Be aware the install stuff described at the
> start doesn't work yet. The reference documentation is also quite
> patchy thanks to doxygen not understanding CRTP. All that stuff and a
> fair bit more remains to fix before it's ready to enter the Boost
> peer review queue.
>

BR,
Matus