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

Subject: Re: [boost] [outcome] Requesting pre-review of Boost.Outcome tutorial
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-11-20 13:29:39

On 20 Nov 2016 at 8:04, Matus Chochlik wrote:

> > 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.

Agreed. It saves so much time when writing systems code. You write 
correct code first time far more frequently. And thanks for the 
feedback and verification I'm on the right track, your implementation 
was interesting to study, it brought back many memories of where I 
faced the same design dilemma and chose differently to you.

> 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.

I can see a few things in your Outcome which would be very hard to 
get past a Boost peer review :)

However your implementation solves a real pain point I too have with 
my Outcome in that if you forget to do something with the returned 
Outcome, the error state gets lost. This encourages too easily 
programmer error. If you use my Outcome in C++ 17 or better it marks 
my Outcome with the [[nodiscard]] attribute which at least gets you a 
compiler warning in certain configurations of some compilers which is 
better than nothing, but I sure do agree it would be nice if you 
could metaprogram the compiler to check that code is doing something 
reasonable with a returned outcome. Unfortunately a major missing 
part of C++ metaprogramming is the ability to tell the compiler stuff 
like this. Maybe a custom clang-tidy check might one day solve this 
properly.

BTW to all those interested in Outcomes, firstly thanks for all your 
feedback. I'll try to get the documentation fixes done by end of 
January - I have coursework deadlines for the end of my Maths degree 
and a new baby slowing me down considerably between now and then. I 
hope to send Outcome to the peer review queue in time for the ACCU 
2017 conference in April.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/