Re: [boost] Outcome v2 (was: Re: Error handling libraries and proposals)

Subject: Re: [boost] Outcome v2 (was: Re: Error handling libraries and proposals)
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-11 17:13:56

On Tue, Jul 11, 2017 at 1:08 AM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> outcome<handle, std::error_code, std::filesystem::path>
>
> ... 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.