I think Niall's choice is a practical one: if you must compromise the interface anyway on one or the other side of the function, at least optimize for performance: implementing the "empty" state comes for free.
It's definitely the case that internally you always need to have an empty state unless you are using Anthony's Williams' double buffer design to enable variants to never ever be empty. But Outcome's API choice was based from the beginning on choosing a ternary logic for the public API. I personally think it's a great fit which is why I chose it, but I appreciate the majority thinks these sorts of class ought to have binary state. Hence Expected's design. As I mentioned to Peter, if you really hate the ternary logic, just don't use the other state. Then you get boolean logic. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/