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

Andrzej,

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?

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?

At some conceptual level, yes, `outcome::expected` is like `variant`. Two other types from this library could also be described in terms of variant: `outocome::result<T>` is like `variant` `outocome::outcome<T>` is like `variant` 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 = variant;' 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 would give us all we need. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu