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

Thanks Vicente,

...

...

...

There is still this case where you want to avoid exceptions in one part of the program, but still use exceptions in other parts of the program. For one example. in one "task" you launch another task with a callback function `f`. You might want to throw from `f` and this is valid. But the framework for launching tasks cannot afford to spill exceptions, so they have to catch and somehow transport the exception (e.g., by exception_ptr) then in the other task, you might want to re-convert to an exception. (something similar to what std::future does.) I understand what you're saying, std::future needs a (conceptual) variant to store its state. So if I hear you correctly, outcome::expected could be used for that. I believe that yes, the underlying type of a future is an expected. Once the future is ready it has an expected in. I believe that we could even have it at the interface level. For me the future::then function should have a expected parameter, as this is the value you can find when the callback is called. But one thing at a time. First we need expected in the standard. Nod, I tend to agree with this. Even if calling the continuation with a variant would give us the same semantics, especially with the monadic helper functions you mention below. Glad to hear you like them.

...

...

...

Also, maybe you will find of use the following example that tries to illustrate the basic use case of the library: <snipped code example>

Thanks, I think I've seen this in the docs. All of this could have been done with a variant without changing the semantics, yes? With the code it will be easier to answer :) Sorry, I was unable to find it.

If we had some PossibleValued, MonadError interfaces, variant could be enough. As most of us we know Either T E is a Monad Error once we do the mapping. But we don't have them yet (at least not in the standard. Yes, I'd rather have those monadic functions which could generically work with any conceptually matching type than a special expected<> which mostly duplicates functionality provided by another (already existing!) fundamental type (variant<>) Yes, but std::variant doesn't ensure the never-empty warranties. As I said in another post I would like to have some std::variant that ensures

Le 25/05/2017 à 14:41, Hartmut Kaiser a écrit : that. Anyway, I fill that is is clear to return a expected than a variant, and not al the people is used to use the monadic interface. A lot of people fill more comfortable with the interface of a Possibly Value type where we have accessors.

...

...

So I guess the next question I would like to ask is: what is the benefit of using outcome::result<T> over std::optional<T>, and outcome::expected over std::variant? Can I try to answer what are the benefits of using std::optional<T> instead of variant? The same answer should apply to your last question, isn't it? Even if variant may be semantically somewhat equivalent to an optional<T>, the mere fact that you have to deal with nullopt_t makes the former awkward to use. In the case of variant/expected no additional awkwardness arises (AFAICS), especially if we had those generic monadic functions.

In order to be fair, we will need variant. And if we wanted the constructor from T to be explicit (thing that we don't have yet) we will need variant. Note that in Haskell every type has a type constructor and Either T U = Left E | Right U expected_type and unexpected_type play the roles of Left and Right for expected.

The only effect from introducing expected<> over variant<> + monadic functions would be a nice bulk of near duplication of code. If we had those (functions), then a simple using expected = variant; would do the trick to even get the same syntax.

If we had a variant with the never-empty warranties, the implementation of expected will be not only simple, but also very short. Hopping the expected proposal will push to have a strong std::variant for C++20. Best, Vicente