Re: [review][LEAF] Review of LEAF starts today : May 22 - May 31

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-05-29 13:19:41

>   - What is your evaluation of the design?

I like it.

>   - What is your evaluation of the implementation?

I like it.

>   - What is your evaluation of the documentation?

Very good.

>   - What is your evaluation of the potential usefulness of the library?

Pros:

1. It is a logical extension of Boost.Exception.

2. It is more useful and better than Boost.Exception.

3. It delivers 99% of C++ exceptions, without requiring C++ exceptions
enabled globally. For those users who work in a C++ exceptions globally
disabled environment, but do have TLS available to them, this solves
that exact audience.

4. It delivers pattern matching catch handlers as a library
implementation, no small feat. We'll be waiting at least until C++ 23
for this to reach the language.

Cons:

1. Me personally, if I want to write success-orientated logic where I
don't write out, inline, what happens for each failure, I just write
code which uses C++ exceptions. I mean, there is a perfectly good
implementation of LEAF already shipping with every C++ compiler for the
last twenty years. It is called "C++ exception handling".

2. I, personally speaking, think that the shops which globally disable
C++ exceptions do so because they specifically wish to ban the use of
C++ exceptions type code in their codebases. Ergo, they would also ban
the use of LEAF, because this exact pattern and style of code is what
they are banning, and globally disabling C++ exceptions is a simple way
of achieving this.

3. For those codebases which really DO want C++ exception handling, but
can't enable it for space or determinacy reasons (i.e. embedded, GPUs),
the reliance on TLS is a showstopper. Back when I designed Outcome, in
order to be as broadly useful as possible, I very deliberately made sure
that the design would work well in (a) consteval evaluation contexts, so
we can implement compile-time error handling using Outcome and (b) in
non-TLS-capable environments such as embedded systems and GPUs.

4. The lack of built-in support for C++ Coroutines I find unfortunate.
Outcome was initially designed to be compatible with C++ Coroutines, but
I never thought it would become a major use case for Outcome back at
that time. It has since become evident to me that C++ Coroutines is a
very major use case for Outcome, because C++ Exceptions and C++
Coroutines are an ugly fit riddled with nasty gotchas, so it's just
easier to make everything noexcept, wrap your coroutine bodies in
try-catch(...) to trap coroutine frame allocation failure, and
exclusively return outcome::result<T> from all your coroutines. Now
that's quite a bit of tedious boilerplate working around what is a
defect in the C++ 20 spec, but it works. But what I think I, and lots of
others, really would prefer instead is for something C++ exceptions like
(e.g. LEAF) to seamlessly work well with C++ Coroutines. I think that if
so retargeted, LEAF would have much broader usefulness.

All the above isn't to say that LEAF isn't useful. It's just not
*broadly* useful, in my opinion. And, to be specific here, the specific
niche where LEAF is most useful (gaming) is, in my opinion, the most
likely to refuse to use it for political/org/cultural reasons.

>   - Did you try to use the library? With which compiler(s)? Did you
>     have any problems?

I extensively tested it more than a year ago. I did not test it since
then. It was absolutely fine a year ago, I do not expect anything except
improvement since then. Emil is an excellent engineer.

>   - How much effort did you put into your evaluation? A glance? A quick
>     reading? In-depth study?

More than a year ago I spent a lot of time studying it, mainly to
benchmark its codegen against Outcome, such that I could make a better
codegen Outcome which is v2.2, expected to be merged to trunk end of
2020. I have done very little since, except a cursory overview for this
review.

>   - Are you knowledgeable about the problem domain?

Yes, intimately.

For me personally this library is a weak accept. I can't personally see
any use cases for it, but that's not to say there aren't some out there
who have this exact problem needing solving, for reasons I cannot think
of. And the implementation is high quality, as are the docs, and it's a
straightforward and logical extension of Boost.Exception which is
already shipping in Boost. And because it's that logical extension, that
makes it an accept for me. I just wish it were more broadly useful,
that's all.

Niall