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

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