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

On 31/05/2017 14:11, Andrzej Krzemienski via Boost wrote:

2017-05-31 14:43 GMT+02:00 Niall Douglas via Boost :

...

You do realise there is nothing stopping a person using the valued state to return an error, the errored state to return a value, and the excepted state to return a type erased smart pointer?

Empty state is no different.

The difference is that you have brought it up as an example of where the empty state could be used in practice. In the code written by the author of Boost.Outcome. This is easily taken as usage recommendation.

Use *case* recommendation.

This is the message I got form reading your replies: It is easy to implement and use `outcome` without an empty state in the interface, but without empty state, the use case from AFIO would not work. This is about the only use case you have shown us.

You must have missed my preceding example where we initialise a result<T> to empty before entering a loop which may call a worker function depending on predicates, accumulating its returned result<T> into the stacked result<T>. On loop exit, we test the stacked result<T> for emptiness to see if we ever called the worker function (i.e. satisfied the predicates at least once). This use pattern saves on a separate "bool found = false;" Most usage of result<T> in AFIO never uses the empty state, in fact, I think it actually the case that AFIO *never* intentionally uses the empty state internally nor externally. It's what attracts me to a non-empty-capable result<T> type. KernelTest does make substantial use of the empty state though.

...

...

I can understand that, but I'm not sure I can entirely agree with it. As previously mentioned an error_code return is supposed to indicate a non-exceptional error, while an exception is exceptional. So this feels like promoting a non-serious error to a serious error.

Sure. But this semantic also means that errors don't get accidentally lost if the programmer checks for an exception without checking for an error. I figured that to be a safer default.

So this is to prevent accidental user bugs? Or rather the consequence of the mental model where "error" means either error_code or exception_ptr?

Let me repeat: **exceptional** means either error_code or exception_ptr. **error** means only error_code. You can think of it like this: failure to explicitly check for an error results in an exceptional circumstance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/