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: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2017-06-07 15:02:38

On Wed, Jun 7, 2017 at 6:43 AM, Niall Douglas via Boost
<boost_at_[hidden]> wrote:
> 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.

There was talk (not sure if it was an official proposal or just a
suggestion) of something like
decltype(return)
for getting the type returned from the current function.

> 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/
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost