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