Re: [boost] Boost.Outcome review - First questions

Subject: Re: [boost] Boost.Outcome review - First questions
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-23 18:58:31

Le 23/05/2017 à 15:45, Andrzej Krzemienski via Boost a écrit :
> 2017-05-23 0:44 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:
>
>> Niall Douglas wrote:
>>
>> But you might be onto something. Some other combination with value_or()
>>> might well produce a reference to a deleted temporary. That would explain
>>> the choice of value returning semantics for value_or().
>>>
>> Having value_or at all is wrong. expected shouldn't have it. It encourages
>> people to drop the error code on the floor.
>>
>> value_or is fine for optional, where there is no error code to erroneously
>> ignore. An optional return tells you nothing about the reason it could not
>> produce the value you asked for.
>>
>> expected does give you the reason. This reason should be acknowledged, not
>> ignored or silently dropped.
>>
> +1 for all this about value_or()
We had expected::catch_error in the original expected proposal. I have 
moved this now to monad::catch_error.
>
>
>> This is but one example in which "consistency" (in this case between
>> optional and expected) makes an interface worse. These two are different
>> things, they shouldn't be consistent. op->? Really?
I don't believe that opt-> is better than exp->. We don't have yet a dot 
operator, this is why we use ->.
>>
>> This is also why I don't care much for Niall's decision to include
>> option<T> in his library, with the consequent bubbling up of option's
>> properties (such as the ability to have an empty state) upwards into
>> result/outcome.
>>
> I agree: I find it difficult to imagine where `option<T>` would be of use.
> On the other hand, empty state is not something inherited from `option<T>`.
> It is simply that you need it to have a simple implementation of
> `result<T>`. What would a default-constructed `result<T>` do?
I agree that empty doesn't  add any value in those 2 cases.
>
>
>> Sure, now that one has the empty state, one can make it do something
>> useful, such as make error() throw when empty, so that its utility becomes
>> a self-fulfilling prophecy. But it shouldn't be there. result/outcome would
>> be cleaner and more elegant without option and the empty state (and
>> result<T> could be brought as close as possible to expected<T, error_code>,
>> an equivalence everyone expects.)
>>
> Agreed. But maybe it is not implementable without costs exposed even to
> users (like performance).
>
This is my main concern about the generalization via policies design.

Vicente