Thanks for the interest. On Sun, May 3, 2020 at 4:15 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
It can service the environments where TLS is affordable.
You're assuming that the use of TLS pointers to error objects in LEAF, moving error objects directly to the scope where they are needed, bypassing return values and stack frames, is less efficient than transporting them in return values. Depending on your platform and your error object types, it could go either way. Separately, LEAF can transport any number of error objects of arbitrary types without dynamic allocations. If you need to do this with a conventional result<T> implementation, you'll be allocating memory. That may be as much of a showstopper as unavailability of TLS could be for LEAF. For a similar reason, I find the comparison with Boost.Outcome, at the end
of documentation, unfair. If the goal of this comparison is to help people decide which library is best suited for them, LEAF or Outcome, the usage or non-usage of TLS is an important factor.
It's important but not in terms of efficiency, only in terms of availability and suitability. LEAF is not suitable for coroutines or GPUs (though GPU code doesn't need much in terms of error handling anyway). LEAF works well with async code based on threads, see: https://github.com/zajo/leaf/blob/master/examples/capture_in_result.cpp?ts=4 (without exceptions) https://github.com/zajo/leaf/blob/master/examples/capture_in_exception.cpp?t... (using exceptions)