I'd therefore be happier with default construction giving uninitialised contents, or a default constructed T or E. No overloading state of E.
result and outcome have no E. I'm not talking about E or expected
here. I'm talking specifically about result<T> and outcome<T>. That is, I'm trying to answer the question "Under the assumption that expected doesn't exist, what should the default constructor of result<T> do?" Default constructing to an std::error_code of 0 is kind of stupid because "The operation failed: The operation succeeded", although one might, I suppose, make an argument in favor of constructing into a stupid state precisely because it's stupid.
I'd choose uninitialised bytes or default constructing T before default constructing E to a null error_code. As I've mentioned many times now, default constructed error_code is only by convention not an error, the unfortunate choice of the system_category by the C++ standard makes it not portable to assume a default constructed error_code is not an error. If people did agree with me that a default trapping empty state is particularly useful in debug builds, the obvious choice for a release build default is uninitialised bytes. As Vicente mentioned, valgrind and the AddressSanitizer should catch misuse of those. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/