Subject: Re: [boost] Boost.Outcome review - First questions
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-22 22:44:48
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.
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.
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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk