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
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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk