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-11 17:33:55

Am 11.11.2016 um 22:37 schrieb Niall Douglas:
> On 11 Nov 2016 at 21:23, Klemens Morgenstern wrote:
>
>>> an explanation and a sort of tutorial explaining the history and
>>> purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd
>>> greatly appreciate if people could tell me:
>>>
>>> 1. Does it make sense?
>> Yes, it does. Especially for embedded development, this seems very useful.
> Oh great. Thank you. I was worried it was too long and/or boring
> and/or confusing.
I am familiar with the problem, because I'm actually planning to work on 
an stm32 periph-library, for which I need a solution for that exact problem.

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.

>> Is there a way to switch the behaviour depending on whether exceptions
>> are available? I.e. throw if they are, elsewise use the result? Or would
>> you consider this a horrible Idea?
> Already present. All exceptions are thrown via a user redefinable
> macro. Each individual throw gets its own macro. When exceptions are
> disabled in the compiler, the default implementation dumps a
> stacktrace and terminates the process, but user code can do anything
> else it feels like.
>
> I would add that it should be the case that if properly used Outcome
> never throws an exception, not ever. Therefore it should never
> terminate the process.
>
> One thing I'll add before peer review is an optional facility that it
> will cause a link error if your code ever could cause an exception to
> throw. This should aid debugging.
Intersting, how would that work? And if I disable exceptions 
(-fno-exceptions) I'd already get an error.
>> The reason for me would be, that I could write a library which's user
>> could use it both ways, depending on what he has available. I think if I
>> wanted to provide a way to have a function-call using an exception or an
>> error_code, I'd go with the C++11 way, i.e. distinguish this in the
>> signature. So for me the main use-case would be, that  exceptions might
>> not be available.
> This is major use case intention for Outcome and exactly what I use
> it for myself.
>
> Thanks for the feedback Klemens.
>
> Niall
>