Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-07 10:43:12

On 07/06/2017 00:02, Gavin Lambert via Boost wrote:
> On 6/06/2017 21:23, Niall Douglas wrote:
>> Also, if you want the TRY operation to work (and you really, really do,
>> it is an enormous boilerplate saver), then your error type needs to be
>> identical throughout your program. Templating it breaks that.
> 
> Why does it need to be identical?  Can't you just use
> decltype(r.error())?  As long as you know that at minimum it supports
> the error_code interface this should be sufficient for most purposes.

It doesn't work unfortunately because you need to convert from
error_code interface compliant type A to error_code interface compliant
type B, and what does "convert" mean exactly? Remember, the TRY
implementation can have no knowledge of what the return type of the
enclosing function is. It has to return something, safely, which will
propagate the error code correctly.

Sure, the programmer can build in conversion routines between error code
interface types, we could even use a free function based design so
arbitrary third party controlled types can be converted from and to. But
to be honest at this stage of complexity you're better off using exceptions.

>> I am currently minded to have error_code_extended no longer store a 191
>> byte string which lets me pack many more of them into a reasonably sized
>> ringbuffer. If people want to store a string, I am minded they should be
>> either supplying a static const char * or else return an outcome<T> with
>> shared_ptr payload to strings.
> 
> How would they do such a payload for an error case?

For result<T>, your payload will probably be restricted to two 64 bit
pointers. Up to you what those mean (and how you'd garbage collect
them). I may allow people to create a secondary ring buffer and
implement some sort of chaining facility, that way they could set up a
fixed sized string facility if they wanted to.

For outcome<T>, use the shared_ptr facility to deliver arbitrary
type-erased payload.

Niall

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