I am not trying to propose any new logic here. I am trying to assign some mental model to what `outcome<T>` currently does. Consider: some funciton `f` is supposed to compute an `int`. But the computation may fail, in this case I want the function to return the reason why it failed. Also, it is possible that I will get some "internal error". For this reason funcio `f` returns `result<T>`:
``` result<T> r = f(); ``` Now, `r` can represent the following states:
``` if (r.has_value()) // value successfully computed {}
No, the correct interpretation here is that the result returned has a value, not that the value was successfully computed.
else if (r.empty()) // internal error {} else if (r.error()) // reason why f failed {} else if (r.has_error() && !r.error()) // what is that??? {}
Similarly to the value returned case, Outcome does not involve itself into whether a T value returned is valid or not in exactly the same way as it does not involve itself into whether a E value returned is valid or not.
The last case is neither a value, nor a reason for failure, nor an "internal error". How should a caller interpret it? Two possible answers:
1. There is a fourth state with no intuitive or sane interpretation. 2. Assume this never happens. If it happens it is a bug in calle site that needs to be fixed.
You've got to remember all these potential state flow paths never occur in any real world code base. You'll even see the compiler eliding in the assembler output any handling of an empty state being returned if it can see that that is not possible. Same goes for if you return only ever a value. The result<T> effectively "disappears" in the assembler generated, and it is as if you returned a T directly. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/