Re: [boost] [outcome] Ternary logic -- need an example

...

I don't know if it would be worthwhile to try to optimise storage for that case. [result]

An interesting point, because this is an argument in favor of returning by value from result<>::value() - I can synthesize an optional<T> on demand instead of storing one. (Return by reference mandates having an optional<> object stored.)

I did consider returning optionals which might be empty instead of throwing an exception. Syntactically, the user must then do the check for state after the .value() if they want to avoid a throw, plus you now get ugly outcome.value().value() everywhere. I felt that undesirable.

Also applies to other possible combinations such as expected, E2>, outcome>, and so on that can all in principle be flattened into a single variant under the hood.

Earlier Expected proposals had all sorts of useful semantics for nested expected. They have been removed from the most recent proposal. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/