We don't need to depend on guaranteed return value elision. There is an emplacing constructor, an initializer_list constructor, and the observers return references. So one does not need a default constructor, nor copy nor move.
How are you going to return it from a function then? That's what these types are, function return values.
That's an interesting observation. Vicente, when he reviewed Outcome's docs, was pretty appalled at how error handling focused they are. His view is that Expected is an EITHER monad where E is exactly like T, and he was not happy that Outcome presents Expected as if it is solely for use for returning stuff from functions. And, he is right. Expected has a raft of other uses especially in functional metaprogramming, and Outcome and its docs does not do justice to any of those other uses. But my counter argument is that 70-80% of people out there currently don't care about those other uses. I know this from having to completely rewrite the Outcome docs three times. They currently only want to know about error handling. So I made the docs all about that only. A non-copyable nor moveable expected<T, E> is no use for returning stuff from functions, but I can see that such a thing might be useful for other stuff e.g. a less awkward to use std::variant for some limited set of variant types. I haven't given it a huge amount of thought yet to be honest, but the Expected proposal document is very clear that non-copyable and non-moveable types are permitted. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/