Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-02-04 12:01:17

>>> If all Outcome did was transport values, error_code and exception_ptr,
>> I'd
>>> support it.
>>
>> Last review it was widely agreed that being able to transport arbitrary
>> payload with error_code was a desirable thing. I appreciate that you're
>> not the whole community Emil, but that's the feedback I was given last
>> review, and this library implements what the community asked for last
>> time we were here.
> 
> exception_ptr _is_ arbitrary payload.

exception_ptr type erases and calls malloc. Its use cannot be elided by
the compiler, due to the use of atomics.

The `trait::has_error_code_v<E>` mechanism lets you return arbitrary
payload without those overhead, but at the cost of extra brittleness
introduced into the type system. One can, at any time, further up the
call stack do the type erasure then, and regain flexibility by removing
from the type returned returned the arbitrary payload. I do this myself
in my own code: as a stack unwinds, make type erased the unwind by
throwing a custom exception type containing type erased arbitrary payload.

All this sounds complex I am sure. But in practice when writing the code
it all follows naturally, and the code is clear regarding its intent and
purpose. It just is probably a bit new to some folk, that's all.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/