Subject: Re: [boost] LEAF has been refactored, it now has a much simplified error handling interface
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-01-29 20:06:38
On Tue, Jan 29, 2019 at 1:36 AM Andrzej Krzemienski via Boost <
> År., 16 sty 2019 o 20:51 Emil Dotchevski via Boost <boost_at_[hidden]>
> > LEAF is a C++11 error handling library for use in low-latency
> > I'm looking for a Boost Review Manager. Any one of you good people
> > to volunteer? :)
> > https://zajo.github.io/leaf/
> > Features:
> > -Header-only, no dependencies.
> > - No dynamic memory allocations.
> > - Any error-related object of any movable type is efficiently delivered
> > the correct error handler.
> > - Compatible with std::error_code, errno and any other error code type.
> > - Support for multi-thread programming.
> > - Can be used with or without exception handling.
> Hi Emil,
> In the docs we can see that one of the requirements for result<T> is that
> "T must be movable, and its move constructor may not throw."
> This seems to preclude guard-like types that are not movable to be
> from functions via result<T>. Like std::mutex. When a wrapper type is
> returned by value there is no need to move the internally stored T. At
> in C++17. In principle, a wrapper should not require the wrapped type to
> movable. Types like boost::optional or outcome::result do not have this
> requirement. They provide an "in-place" constructor for this purpose. Is
> possible to lift the requirement in leaf::result?
> Also, the part "move constructor may not throw" is a bit ambiguous. It
> could mean:
> 1. The program will not compile unless T's move constructor is annotated
> `noexcept` or `throw()`.
> 2. If a move constructor of T is invoked and it ends by throwing an
> exception the behavior of the program is undefined.
> IOW, can I pass types potentially throwing from move constructors (like
> std::list<int>) at my own risk or is it statically prevented?
Thank you for looking into this. You're right, the documentation is
imprecise. The answer is that leaf::result<T> is a variant<T, int,
std::shared_ptr<>>, so the restrictions on move/copy etc are restricted
only by T (LEAF is exception-safe).
I should also add that in its current iteration (that hasn't yet made it to
master), LEAF can work with 3rd-party result types, and in addition is able
to transport the error associations (e.g. the int) in a std::error_code.
This brings interoperability to a whole new level: if you have a 3rd-party
API able to report a std::error_code in case of errors, LEAF can propagate
any number of error objects through that API.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk