Re: [boost] [outcome] Requesting pre-review of Boost.Outcome tutorial

Subject: Re: [boost] [outcome] Requesting pre-review of Boost.Outcome tutorial
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-11-12 08:10:15

Am 12.11.2016 um 09:53 schrieb Niall Douglas:
> On 11 Nov 2016 at 23:33, Klemens Morgenstern wrote:
>
>> I just had another idea (I hope I didn't miss that): it would be awesome
>> if there was some way to deal with objects, that might have an errornous
>> state. I.e. something like that:
>>
>> outcome<path> p1("-invälid#value"); //error set
>>
>> outcome<path> p2("valid-value"); //not set
>> int i = p2->something_errornous(); //now I have a set error.
>>
>> I'm not sure how to do that, but maybe something like this: the ctor
>> checks through std::is_nothrow_constructible if the last argument can be
>> std::error_code or
>> something like that and then takes this one to capture the error;
>> elsewise it catches the exception.
>>
>> And for the member-functions you could use some indirect call, like this:
>>
>> p2.invoke(&path::something_errornous);
>>
>> Which then calls the matching function with an std::error_code or the
>> exception. I'm not sure if that should return outcome<int> or int and
>> put the error into p2.
>>
>> This would be useful for a library, which uses the std::error_code or
>> exception pattern, because it could be integrated with your library very
>> convienently.
> I'm not sure if I understood you correctly, but you might be wanting
> to do pattern matching based on the contents.
>
> Outcome has that, so:
>
> outcome.match(callable) will call the appropriate overload of
> callable(T | error_code | exception_ptr). This is very handy.
>
> We can also do monadic bind on the state e.g.
>
> outcome >> [](error_code){ /* only called if outcome contains an
> error_code. We can return a new type of outcome here used by
> subsequent bind operators i.e. we can be an error_code
> filter/converter */ };
>
> There are also operators:
>
> outcome<int> | 4;  // If outcome is empty, errored or excepted,
> return outcome<int>(4)
>
> outcome<int> & 5; // If outcome has value, return outcome<int>(5)
>
>
> If however you were talking about tombstone values i.e. special
> values of T with special meaning, Outcome does not currently provide
> that but could be extended to do so by someone who isn't me very
> easily (pull requests welcome). SG14 already were interested in an
> Outcome with packed state using tombstones to reduce storage size,
> Outcome does already store bools and void and all outcome state into
> a single packed byte when possible.
Ok, I did miss the match, call, but that's basically to get the error 
out of the outcome. I meant the other way around: let outcome 
automatically capture the errors of the ctor automatically.
I've tried to put together an example, but I failed to get it right with 
the parameter forwarding, so that (https://godbolt.org/g/UdKzFs) doesn't 
work properly. I'm not sure if there is a good solution for that, but it 
hopefully demonstrates what I'm talking about.
But since it's not as easy as I hoped, it maybe should not be part of 
outcome, but rather a wrapper holding one. On the other hand, having a 
solution that at least works with ctors, seems important to me, since 
you could have RAII with that while disabling exceptions.