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

Subject: Re: [boost] Boost.Outcome review - First questions
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-23 13:45:20

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()

> 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?
>
> 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?

> 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).

Regards,
&rzej;