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.

`optional>` is still not enough for the `future<T>`, because in `future` `T` is allowed to be an lvalue reference. :) Regards, &rzej;