- 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