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

Le 23/05/2017 à 15:45, Andrzej Krzemienski via Boost a écrit :

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() We had expected::catch_error in the original expected proposal. I have moved this now to monad::catch_error.

...

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? I don't believe that opt-> is better than exp->. We don't have yet a dot operator, this is why we use ->.

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? I agree that empty doesn't add any value in those 2 cases.

...

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

This is my main concern about the generalization via policies design. Vicente