On Sat, May 30, 2020 at 4:28 PM Sorin Fetche via Boost-users <
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.
Is there scope for merging LEAF and Outcome as it seems from (very detailed discussions) that they only partially overlap? 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.
With 20/20 hind-sight, I think that Boost.Outcome was wrong as a name and should have been called Boost.Error or something and both LEAF and Outcome could (if only) now live in that space. Adding code to Boost should not lead to an ever increasing difficulty of choosing the right tool for the right job for end-users.
The discussions here are very detailed but to the casual user that's most probably all lost because (luckily) not all will be reflected in the manual and not all users will have the level of expertise of Boost library authors or time to study the documents extensively. The typical end-user will not be able to make a choice and will make the choice to move on to a 3rd party library where the first line of the
read.me reflects his/her exact problem and use-case and proposes a solution to this exact problem.
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).
degski
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users