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

Subject: Re: [boost] Boost.Outcome review - First questions
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2017-05-25 00:13:08

Andrzej,

Thanks for attempting to additionally clarify what you said before.

> Again, sorry to reply on behalf of Niall, but it is my description that
> might have caused the confusion.

I'm glad you try to answer my questions as I know I will not get any from Niall directly.

> 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<T, exception_ptr> to store its state. So if I hear you correctly, outcome::expected<T, exception_ptr> could be used for that. 

> Other situation, is when you are using a third-party library, which throws
> exceptions. You want to wrap it into a component that does not throw.
> Boost.Outcome also supports in a convenient way this transition from and
> to exceptions.

Ok. 

> 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<T, some_error_type> without changing the semantics, yes?

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<T, E> over std::variant<T, E>?

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu