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