Re: [review][LEAF] Review of LEAF

From: degski (degski_at_[hidden])
Date: 2020-06-01 11:51:30

On Sat, 30 May 2020 at 18:44, Emil Dotchevski via Boost-users <
boost-users_at_[hidden]> wrote:

> On Sat, May 30, 2020 at 4:28 PM Sorin Fetche via Boost-users <
> boost-users_at_[hidden]> 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_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>

-- 
@systemdeg
https://www.instapaper.com <http://instapaper.com>
"We value your privacy, click here!" Sod off! - degski