Re: [boost] LEAF has been refactored, it now has a much simplified error handling interface

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 <
boost_at_[hidden]> wrote:
>
> śr., 16 sty 2019 o 20:51 Emil Dotchevski via Boost <boost_at_[hidden]>
> napisał(a):
>
> > LEAF is a C++11 error handling library for use in low-latency
environments.
> >
> > I'm looking for a Boost Review Manager. Any one of you good people
willing
> > 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
to
> > 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
returned
> 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
east
> in C++17. In principle, a wrapper should not require the wrapped type to
be
> movable. Types like boost::optional or outcome::result do not have this
> requirement. They provide an "in-place" constructor for this purpose. Is
it
> 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
as
> `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?
>
> Regards,
> &rzej;

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.