A program might return an outcome containing a null error_code. It probably is a bug,
Interesting. I need to think about it. But my first response would be. If a user cheats the system in this way, you should not try to rescue the situation.
I can think of two ways of looking at the situation with a value-initialized error code:
1. Class outocme<T> has an invariant: putting it into state where it stores a value-initialized error code is a bug, close to undefined behavior, which means, you can assert() inside and users and algorithms can expect it never happens.
I am afraid I don't understand. A value initialised error code is surely a normal error code? Why would I need to assert stuff?
2. Class outcome<T> can be in yet another state: "strange". So we have the following states: valued, exceptional, errored, empty, and strange. And the user when inspecting the state has to take into account all the five possible states.
Every additional possible state generates more branches for the compiler's optimiser to deal with. I would therefore reject any additional possible states. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/