It is overwhelming to the uninitiated though, so I can see how it might appear to be complex.
Surely that is a sign of complexity. That doesn't mean it is unnecessary complexity, however.
Not at all. Floating point numbers are simple right? But they wouldn't be to someone who has never seen one before. They'd be overwhelming initially until you wrapped your head around them and stopped asking, "why can't this just be fixed point integer arithmetic?"
I would argue that being overwhelmed with the possibilities would be a characteristic of any vocabulary library.
The same cannot be said for shared_ptr, though it probably could be said of chrono.
I remember enormous confusion back in the day about shared_ptr vs unique_ptr and what was wrong with auto_ptr anyway? I remember Dave losing his temper with the argument "nothing is wrong with auto_ptr, don't see any need for any of this totally unnecessary additional complexity". Yet all that is gone now. One day it'll be the same with Outcome/Expected. It'll just be there, and widely understood. People will use it appropriately without even thinking about it.
Perhaps the solution is basic_result and basic_outcome, with result and outcome as special, simplifying cases. That way, most can use the normal, simpler templates, but those needing all of the knobs and levers for a custom use case can use the basic_* types.
Already agreed to this during the review. Tracked by https://github.com/ned14/outcome/issues/110 Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/