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: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-01-29 09:36:13

ś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;