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

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-31 13:43:37

On 31/05/2017 14:11, Andrzej Krzemienski via Boost wrote:
> 2017-05-31 14:43 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:
>> 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/