On Tue, Jul 11, 2017 at 1:08 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
outcome
... could return an open file handle on success, or an error code plus the failing path on failure.
The third parameter, "error info", should not be specified by the error reporting code because what info is relevant to a failure depends on the context, which is not know an the point you report the error.
For example, one could build your Noexcept library with it quite easily, and thus "plug in" to Expected, P0650 etc.
I think Noexcept is a lot more lightweight than you think. The internal machinery it is based on (what I think you imagine your building block would replace) is about 500 lines, out of about 800.
As you saw on SG14, using any black box library routines is always going to be a problem for the fixed latency user base.
What is a black box library routine? If you're referring to the use of TLS, like I said in that thread, it's a constexpr constructor so there is nothing to initialize and no reason for the TLS to be slow. Nobody on SG14 challenged this point, so I'm not sure what you're referring to.
Your library is shorter than mine, but it calls unknown latency routines. Mine never does.
That was addressing your offer to use Outcome as a "building block" for Noexcept. The point is, the "building block" is heavier than the "product". :)
You also impose TLS on your end users. Mine is much lower level than that, if end users wish to combine mine with TLS to achieve your library, they'll find it very easy.
It's the other way around, actually. The use of TLS moves the error objects off the critical path and removes the coupling between errors and error-neutral contexts. These are Good Things. The decision to force users to enumerate their error types (recall again exception specifications) and to move errors up the call chain one level at a time should be justified and supported with data showing that thread_local is too costly in practice. And the thing is, there is no reason for it to be costly. If it helps, think of it as the refcounting support shared_ptr requires: we can call it tricky, but it is not a problem. Worst case, Noexcept has to implement it if it turns out that the built-in support on some platform is inefficient.