Re: [boost] Outcome v2

Subject: Re: [boost] Outcome v2
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-14 16:37:14

On Fri, Jul 14, 2017 at 12:27 AM, Groke, Paul via Boost <
boost_at_[hidden]> wrote:

> > From: Emil Dotchevski via Boost
> > Sent: Donnerstag, 13. Juli 2017 20:12
> >
> > > Have you thought about using a type-erased factory - like
> > > function<exception_ptr()> - as the error type?
> > >
> >
> > exception_ptr needs a memory allocation so that's a no-go.
>
> Yes, exception_ptr needs a memory allocation. And atomic ref counting.
> Which is why I wrote factory function. The idea is that most of the time,
> you don't want/need to inspect the error, you just have to know that it
> happened and maybe be able to pass it on. Which can be very efficient if
> you return a factory.
>
> I understand that this is far from perfect, but it's the best idea I have
> for a single type that can transport arbitrary error information.
> (An alternative would be a functor that throws the exception when called,
> but AFAIK that will be even slower - much slower.)
>

Ah, now I get it, thanks for the explanation. There *might* even be a way
to get this to work even without memory allocation in the end (without
exception_ptr), but I think this is perhaps missing the point of returning
an error object, which is to be able to interact with it. Also, reasonably
if you could fit the things you need to create the object into a "small
object optimized" buffer, you can probably fit the object itself into the
same buffer. Noexcept already has that, it's the result<T> object, however
it might be too heavy to return up the call chain one level at a time (it
is instead designed for capturing the TLS-stored object to postpone its
handling, perhaps after moving it to another thread).