[outcome] Requesting pre-review of Boost.Outcome tutorial
On Fri, Nov 11, 2016 at 8:27 PM, Niall Douglas
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
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/
participants (2)
-
Matus Chochlik -
Niall Douglas