Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Soul Studios (matt_at_[hidden])
Date: 2017-05-12 23:53:40
I welcome a 'expected' implementation, even if, in my testing, results
from this sort of thing are highly CPU-dependent and non-intuitive.
On 12/05/2017 4:19 a.m., charleyb123 . via Boost wrote:
> Hi Everyone,
> ** HEADS UP, NEXT WEEK **
> The formal review of Niall Douglas' Outcome library starts next week
> (Fri-19-May to Sun-28-May).
> Your participation is encouraged, as the proposed library is uncoupled and
> focused, and reviewers don't need to be domain experts to appreciate the
> potential usefulness of the library and to propose improvements. Everyone
> needs (and has suffered) error handling, and can compose an opinion on that
> Outcome is a header-only C++14 library providing expressive and type-safe
> ultra-lightweight error handling, suitable for low-latency code bases.
> Key features:
> *- Makes using std::error_code from C++11's <system_error> more convenient
> and safe
> *- Provides high-quality implementation of proposed std::expected<T,E> (on
> C++20 standards track)
> *- Good focus on low-latency (with tests and benchmarks)
> *- Error-handling algorithmic composition with-or-without C++ exceptions
> *- No dependencies (not even on Boost)
> This review is timely, as C++17 brings us std::optional<T>. The upcoming
> std::expected<T,E> (an implementation provided in Outcome) is a
> generalization of std::optional<T> that provides a <success|fail> value,
> where the unhappy result is a 'std::error_code' or an instance of
> The library further provides 'outcome<T,error-code,exception-ptr>' for
> handling <success|error|exception> to safely wrap throwing APIs.
> ACCU 2017 talk including design rationale:
> Latest tarball:
> Note: Tarball might be easiest; but if you want to clone from GitHub
> directly, after the clone you should run the following command to get the
> source zip exactly: git submodule update --init --recursive
> NEXT WEEK (when the public review is started): Please post your comments
> and review to the boost mailing list (preferably), or privately to the
> Review Manager (to me ;-). Here are some questions you might want to answer
> in your review:
> - What is your evaluation of the design?
> - What is your evaluation of the implementation?
> - What is your evaluation of the documentation?
> - What is your evaluation of the potential usefulness of the library?
> - Did you try to use the library? With what compiler? Did you have any
> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
> - Are you knowledgeable about the problem domain?
> And most importantly:
> - Do you think the library should be accepted as a Boost library?
> For more information about Boost Formal Review Process, see:
> Thank you very much for your time and efforts.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk