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 12:49:17

Andrzej,

> 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>?
> 
> At some conceptual level, yes, `outcome::expected<T, E>` is like
> `variant<T, E>`. Two other types from this library could also be described
> in terms of variant:
> `outocome::result<T>` is like `variant<T, outcome::error_code_extended,
> empty_state>`
> `outocome::outcome<T>` is like `variant<T, outcome::error_code_extended,
> std::exception_ptr, empty_state>`
> Technically, you could use variant everywhere, but the tools from
> Boost.Outcome offer an interface tailored to the use cases, loike
> contextual conversion to bool. Also, a more focused scope than variant
> offers room for optimizations.

All of those could be equally well provided by a set of free-standing generic functions. There is no need to introduce yet another inventory type. As said elsewhere, a 'using expected<T, E> = variant<T, E>;' would do us the same in this case. 

> Having this `empty_state` is under debate.

I hope at least the empty state gets dropped on the floor, even if I think the whole expected<> business is overkill and introducing a minimally necessary set of monadic helper functions (Vicente mentioned PossibleValue, MonadError, etc.) would be sufficient in many ways. With those functions a simple variant<T, E> would give us all we need.

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