As mentioned in another discussion thread, the empty state is also used internally as a micro-optimisation. So it would likely remain internally whatever the decision taken here, as a tool for making the CPU expend identical CPU cycles on both positive and negative branches on state.
Again, if people don't like that behaviour of outcome/result to be equally costly on T or E branches chosen,
What does it mean tha "outcome is equally costly on T or E branches chosen"?
Have a look at https://godbolt.org/g/bVd4D7, specifically the disassembly. As you'll note, the first possible state (empty) tends to be chosen by the compiler as the most likely. That implies a 20 cycle branch misprediction cost for each of the valued or errored states. So they are equally costly, which is intentional.
Resetting to empty looks attractive, but I found out the hard way it is a bad design decision. Code consuming a rvalue reference does not actually have to move anything, nothing in the C++ standard says it does. It's only a widely held convention that it ought to.
In optional<T> we deliberately don't put the moved-from object into an empty state (which surprises many people). This is for performance reasons: when `T` is a trivial type, `optional<T>` can be made trivially_copyable.
+1 Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/