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

2017-05-23 0:44 GMT+02:00 Peter Dimov via Boost :

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, an equivalence everyone expects.)

Agreed. But maybe it is not implementable without costs exposed even to users (like performance). Regards, &rzej;