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

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-05-01 10:45:09

On 01/05/2020 06:57, Michael Caisse via Boost wrote:

> LEAF is brought to us by Emil Dotchevski, the author of Boost.Exception.
> Similar to Boost.Exception, this library allows arbitrary error objects
> to be returned; however, unlike Boost.Exception it does not require
> dynamic memory. The library can be used with or without exception handling.

Before someone inevitably asks what the differences are between LEAF and
Outcome:

- Emil gives his list at https://zajo.github.io/leaf/#boost_outcome

    - Note that his benchmarks are for Outcome v2.1, and Outcome v2.2
(on the "better_optimisation" branch) significantly improves its
comparative benchmarking. It doesn't eliminate the gap, but there are
orders of magnitude improvement. I would like to thank Emil for openly
sharing those benchmarks, and motivating me to invest effort into
Outcome to close the gap. I do want to stress that I have found zero
observable difference between v2.1 and v2.2 Outcome in real world code
on out of order CPUs at least as new as the decade old ARM Cortex A15.

    - I don't otherwise disagree with Emil's summary, though he has a
different starting point and view point of the differences than I would
have.

- For me with Outcome, use of thread local storage and assumption of
reasonable RAM availability was a non-starter. It prevents use of
Outcome in constexpr, Freestanding, GPUs, embedded systems. LEAF can be
configured with some effort to avoid use of TLS, but ultimately it is
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).

- 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, like C++ exceptions it aims to
"disappear" for the sucess control flow. Outcome is
success-failure-balanced, it treats success and failure with equal
priority (though default internally hints to the compiler to expect
success).

- A good chunk of LEAF is the matcher interface, which I personally
think is both cool and much more universal potentially than just for
LEAF. Outcome awaits WG21 to implement language support for matchers.

- Finally, I have actually wrapped Outcome into a LEAF-like
implementation in production code I have shipped. I intentionally and
deliberately left open customisation points in Outcome to make that kind
of extension possible, so if you are on a platform with TLS and plenty
of RAM, you can achieve all the non-matcher parts of LEAF with very
little extra work in Outcome.

I don't mean this to say "Outcome already does LEAF". Rather, I'd like
this to be interpreted as "I endorse the fundamental design proposal
which LEAF makes as I do the same thing in my own code".

Should Outcome offer LEAF-like extensions? Should Outcome and LEAF be
merged? In my personal opinion no. LEAF can already wrap Outcome and
transport it around. Any LEAF-like extension (apart from the matchers)
Outcome could offer is so trivial that I don't think it worth shipping,
users can implement such extensions locally with such little effort
there is no point on insisting on a common implementation, in my opinion.

Finally, my thanks to Emil for bringing yet another high quality library
to use for review, and to Michael for review managing this.

Niall