Re: [boost] [outcome] expected, etc. why are these assignable

Richard Hodges wrote:

...

Forgive me chiming in late, but what is the semantic difference between:

There are various ways to represent the same four-state variant syntactically, and the main difference is in, well, syntax, when referring to it. You could, for example, use

outcome>

(assuming a never-empty tri-state outcome)

or

outcomestd::path>

Completely agree that in this case optionalstd::path is equivalent to variant. My concern is around allowing more than two

On 2 June 2017 at 18:43, Peter Dimov via Boost wrote: main code paths when testing the outcome. It seems to me that all outcomes will either 'pass' in some way or 'fail' in some way. These are the main concerns are they not? By all means the happy path might specialise happiness, but it's still happiness, right? we could argue that some process might partially complete, and that could be captured with: outcome> A partial result is not a failure. Isn't the purpose of outcome to simply offer a non-throwing alternative to exceptions without requiring in/out variables? Or is there some wider use case I haven't thought of? If so, couldn't that be trivially composed as above?

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost