Re: [review][LEAF] Review of LEAF

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-06-01 13:29:59

On 01/06/2020 12:51, degski via Boost-users wrote:

> Is there scope for merging LEAF and Outcome as it seems from (very
> detailed discussions) that they only partially overlap?

My own opinion:

1. You may remember that Emil was one of two people who voted to reject
Outcome back during its review, as he felt that it was the wrong design.
His comments on what would be better back then map well onto what he has
presented in LEAF. I find that very reasonable: (i) he thought he could
do better (ii) he went ahead and did better in his opinion (iii) he is
presenting now what he thinks is better, and is asking Boost for its
opinion on whether he improved things or not.

2. There is long established precedence for Boost containing multiple
libraries that approach a problem from multiple perspectives e.g. we
currently have three error handling libraries, four maths libraries etc.
If LEAF were accepted, you'd now have four instead of three error
handling libraries. And that seems to me just fine, and not out of
precedence.

3. I specifically and deliberately chose to not design Outcome like
LEAF. I thought then, and I still do, that Outcome ought to be great at
all the things no other solution is great at. I think I succeeded on
that. As I already stated in my own review of LEAF, I personally think
that there is already a perfectly good implementation of LEAF shipping
in any C++ compiler of the past twenty years. I don't, personally
speaking, see the value add for choosing LEAF over C++ exceptions except
to tick some box called "C++ exceptions globally disabled compatible".

> I don't think
> that 'we' should keep on adding distinct libraries that partially
> overlap, Existing libraries should be expanded instead, and
> deduplication should be done in a coordinated way (in this case between
> LEAF and Outcome). Something has to be done to stop exponential growth
> of Boost while maintaining flexibility to add code at will.

The best way to stop exponential growth of Boost, if that is desirable,
is to start culling libraries that aren't maintained nor useful. Or at
least publish a documented list of libraries that new code ought to not use.

> As C++ already has exceptions (and will have exceptions light in the
> future), the use-case you presented to use LEAF surgically with C-api's
> seems convincing (it presents a better case than the case of generically
> re-working an exception system that works, is fundamental to C++ and is
> promised to be improved in the future, i.e. it's the safest bet. Any
> library is secured till maintenance ceases, the language/STL
> (exceptions, exceptions light) is a pdf-file (i.e. future proof by default).

The current formulation of lightweight exceptions before WG21 is
literally Experimental Outcome in language form. Same proposed error
object, std::error. It is currently expected that both value-based and
type-based exceptions would exist in future C++, in order to retain
backwards compatibility, as the semantics between the two are not
currently believed possible to be made exactly one-one.

Experimental Outcome works fine in C code, same as how the most recent
proposal for lightweight exceptions also supports C.

Niall