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 > <boost-users@lists.boost.org <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 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
