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

On Tue, Jan 29, 2019 at 1:36 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

śr., 16 sty 2019 o 20:51 Emil Dotchevski via Boost 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>, 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.