On Mon, Jul 10, 2017 at 10:44 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
On 10/07/2017 18:07, Emil Dotchevski via Boost wrote:
Last week it was brought to my attention that there are currently 5 different libraries and proposals for dealing with the problem of reporting errors from noexcept functions, so I thought it would be useful to update the Noexcept documentation with a short section comparing all the different designs: https://zajo.github.io/boost-noexcept/#alternatives.
Some notes on Outcome v2 related to your now out of date comparison:
Thank you for letting me know that the Outcome design has changed, again. :)
* result and outcome can now be error type customised, same as all the other libraries.
Not all the other libraries. The Noexcept design does not force you specify the possible error types for each function because, as we have learned from the exception specifications fiasco, in non-trivial cases (usually in generic library code) it is impossible to know what errors may be returned by lower level functions. If the error handling library forces you to list them anyway, in such use cases the two choices you're left with is to translate (which is prone to errors and usually imperfect), or some form of catch-all, e.g. unique_ptr<void>. The reality is that not everyone is or will be using only std::error_code; ideally, functions should be able to forward errors from lower level code intact.
For example, outcome<void, void, void> is legal, though unusable.
What would be the meaning of outcome<void,void>?
, but for Outcome v2 the new values are:
yes, yes, yes, yes, no, yes, yes, yes.
To me, your note that Outcome is struct-like rather than variant-like means that it does not have strict value-or-error semantics, so the last one would be "no". Also, could you expand on how Outcome can propagate errors from a C-style callback or across language boundaries? I'm referring to use cases like these: https://zajo.github.io/boost-noexcept/#example_lua