On 31/05/2020 00:43, Emil Dotchevski via Boost-users wrote:

On Sat, May 30, 2020 at 4:28 PM Sorin Fetche via Boost-users mailto:boost-users@lists.boost.org> wrote:

...

Excellent as it allows bridging multiple error handling strategies and usage patterns in an efficient way. I view it as a clear successor to Boost.Exception and has very good interoperability with Boost.Outcome.

Thanks for highlighting this. Indeed, you can use outcome::result<> instead of leaf::result<>, and still use LEAF to handle errors; it does not have to replace any library already in use, it could be deployed surgically in a large code base, to get error objects transported in a tricky case or two.

I should add that those who use Experimental Outcome do so because status_code can transport arbitrary payload in the result's E type. If the payload is non-trivial, a common strategy is to store it in a singleton, and pass a unique identifier to that item in the singleton in the payload. This is not dissimilar to the technique which LEAF provides. Niall

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

On 01/06/2020 14:48, degski wrote:

On Mon, 1 Jun 2020 at 08:30, Niall Douglas via Boost-users mailto:boost-users@lists.boost.org> wrote:

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.

i am obviously oblivious to what 'is in front of', but knowing that now [what light weight exceptions entails], I concur with you. As I noted in that same post, I 'get' [in respect of LEAF] the use-case of a c-api error-handler (but there must be plenty of those, no?), but otherwise I don't see it. From my personal perspective, I would not hesitate one second to use Outcome now, instead of any other solution better, or worse, just because it is going to be in some shape or form, but very similar, in the future standard.

Just so nobody misinterprets anything, right now EWG is not keen on proposed lightweight exceptions. Microsoft hopes to modify MSVC to support an implementation in the near future, and that may change EWG's opinion. LEWG is keen, so far, on the library side of things i.e. std::error and the wider status_code machinery. We recently ported a large codebase at work from to status_code. It took about a day, and the status_code edition is considerably more flexible and useful (mainly thanks to that custom payload feature, and strongly typed code objects). The ability to quickly wrap custom enums into custom status code domains is a nice timesaver too. I should stress though that status_code natively recognises std::error_code, it automatically wraps any custom std::error_category into a synthesised custom status_code_code, so you can totally mix the two in the same codebase, and it'll all "just work". Current committee direction is that C++ 23 should get std::error and a implementation of Outcome's result<T> as std::result<T>, with E hardwired to any type deriving from std::error. This isn't as good as lightweight exceptions, but if EWG changes its mind, the library side of things is ready to go. And obviously everything I just said could change next meeting. Niall