This takes us back to "what if due to a logic error the code that should build `foo` doesn't?"
And since you've constructed `ret` to non-empty, the point of empty is, again, lost. But if I am writing my implementation that way, it is because there is no purpose here to my function returning empty. Else I would implement it differently.
If the function can not return empty it should use another type, isn't it?
Well that's exactly the crux of the debate isn't it? How much should the specific type of object you choose to return T|E exactly match the contract of that function? It's easy to say "exactly match". But in a large code base, too many slight variants of an Outcome significantly increases cognitive load on programmers having to remember what each one of dozens of Outcome variants mean and how they are slightly different. Nevertheless, I can see a good argument for result<T> vs result_e<T> as you suggest. It does increase the clarity of the API's public contract. But one can also go too far. I think, in combination with my proposed typedef factory, we can reach a happy medium somewhere. Obviously there would be implicit conversion from outcomes incapable of empty state into outcomes capable of it, but not the other way round. So like at the moment you can return a result<T> into something accepting an outcome<T> implicitly, you could implicitly return a result<T> into something accepting a result_e<T>, where result_e<T> is empty | T | error_code_extended. What do you think? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/