Re: [review] [LEAF] LEAF Review Starts May 22

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2020-05-01 21:54:02

On Fri, May 1, 2020 at 3:45 AM Niall Douglas via Boost <
boost_at_[hidden]> wrote:
> cleanest to use with TLS, and almost everybody who wants deterministic
> failure and doesn't mind TLS (gaming folk mainly) will find LEAF with
> TLS natural. I don't think LEAF would work well on systems with 2Kb of
> RAM, whereas there are people using Outcome on such systems (judging
> from bug reports filed).

Re:TLS, someone may think that LEAF stores error objects in TLS. It does
not, the error objects being communicated are stored on the stack. There
are no dynamic allocations.

In terms of portability, LEAF is a C++11 library. It requires TLS or,
alternatively, BOOST_NO_THREADS. On systems with extreme RAM limitations it
could be more efficient than Outcome or less efficient, depending on the
use case.

> - For me with Outcome, I wanted every potential control flow inversion
> point to appear explicitly in the source code. Then code could be
> audited much more easily for correctness in both the failure and success
> code paths.  LEAF is success-orientated.

This is not true, the design of LEAF has no happy path bias, but it does
have a bias towards the common case where lower level failures are
forwarded up rather than handled. This makes sense, since there are many
more scopes that only check for errors, than scopes that handle errors.
When a failure is detected, error objects are moved directly to the correct
error-handling scope, while the intermediate scopes are limited to
inspecting the discriminant and communicating it up. It can be said that
LEAF doesn't bother to deliver error objects to scopes that have no use for
them.

> Should Outcome offer LEAF-like extensions? Should Outcome and LEAF be
> merged? In my personal opinion no.

I think these are the wrong questions to ask, as they're based on the
presumption that C++ programmers can agree on using a single all-powerful
error-handling interface that devours everything else. The design of LEAF
is based on the understanding that in any non-trivial program there will be
many different error-handling interfaces, so the focus is on helping the
user communicate arbitrary error objects efficiently and as safely as
possible, using any available mechanism. For example this program uses LEAF
to handle errors, even though functions which may fail return
outcome::result<T> rather than leaf::result<T>:
https://github.com/zajo/leaf/blob/master/examples/print_file_outcome_result.cpp?ts=4
.