Re: [boost] [outcome] On the design and documentation

2017-05-26 9:03 GMT+02:00 Vicente J. Botet Escriba via Boost < boost@lists.boost.org>:

Le 26/05/2017 à 08:22, Thomas Heller a écrit :

...

On 05/25/2017 07:28 AM, Vicente J. Botet Escriba wrote:

...

Le 24/05/2017 à 21:44, Thomas Heller via Boost a écrit :

...

...

First of all, I don't agree with the strong (conceptual) relationship between optional (be it boost:: or std::experimental) in such a way that expected is a generalization of it. From what I understand, the purpose of expected/outcome/ result is to be used as a mechanism to return the result of a function. As such it should also expose the semantics of it. Fortunately, we already have a (asynchronous) return object standardized (std::future). And this is my basic disagreement here: Why not model expected in the lines of future? With the main points being: - expected being movable only - expected::value() should always return by value and invalidate this. - (I would really prefer the color .get though ;)) So the question to Vicente/Niall is: what is the motivation to make it "optional-ish"? Do we have use cases which make this design undesirable?

expected is a generalization of optional as it is synchronous and could return more information about why the the value is not there.

Right, I can see this argument now, let me try to rephrase it a little bit (correct me if I got something wrong please): We want to be able to have a mechanism to return (or store) a value which might not be there, and we need to know why it is not there. The class that's currently available which almost does what we want is optional, in fact, it is already used in such situations, so what we miss is the possible error. So here we are, and then we naturally end up with something like variant. Makes perfect sense.

My line of thought was mostly influenced by the property of being solely used as a return object. And well, we already have the asynchronous return objects, so why not go with something a synchronous return object which represents a similar interface/semantics.

With that being said, I am still not sure if the result of both ways to look at it should converged into the same result.

expected could be seen as the ready storage of a future.

...

future::get block until the future is ready and then returns by reference :)

Except not quite ;) excepted indeed sounds like the perfect fit for the value store in the share state. The only problem here, is that it really requires some kind of empty (or uninitialized) since the value is only computed some time in the future (this is motivation #1 for the proposed default constructed semantics), having either a default constructed T or E doesn't make sense in that scenario. So it is more like a variant.

From a high level I will see it as optional>. We optional because we have in addition the not-yet-ready state. Once the future becomes ready we have expected. I understand that the implementation optional> could be variant. The implementation of expected could store as well variant, but this makes difficult to extract the ready value as variant is not convertible from variant. So there are two possibilities for future::then * status-quo pass the future as parameter of the continuation * make it possible to cast variant from variant and pass expected to the continuation

I proposed other future functions (next and catch_exception) long time ago to manage with the success and failure branches, so that we don't add any constraint in the way the contents is stored.

Resuming, you are right expected will not help as a value type representing the ready state without major changes.

BTW, is the scope of use cases we want to cover with `expected` outlined clearly? People arrive at different optimum solutions when they start with different goals in mind.