Outcome doesn't do SFINAE on its main constructors. It relies on simple overloading which is much lower compile time cost. Maybe it has lower compile time, but it is not correct, isn't it? Would you suggest that std::expect shouldn't do SFINAE?
Outcome's Expected provides both a subset and a superset of your Expected proposal. I have promised to track closely your proposal paper, but I have no interest in providing a perfect match to your proposal. Outcome lets you seamlessly mix expected<T, E> with Outcomes and with *any arbitrary third party error handling system* thanks to the policy based core implementation. It therefore cannot exactly implement your proposal, it needs to differ because it *is* different. My claim is that any code written to use LEWG Expected will work exactly the same with Outcome's Expected. If it does not, I will repair Outcome's Expected until code using it works identically. I think this a very reasonable position to take, especially as you are still changing the proposed Expected. At the risk of slightly losing my temper, I need to say something I'll probably regret later when people throw axes at me. But it's been building for a few days now, and I need to vent. Both you and Vinnie have called Outcome "over engineered". I respectfully suggest neither of you understands the purpose of Outcome the **framework** which is to provide a very low overhead universal error handling framework. That's why there is the exact same CRTP policy based basic_monad class being typedefed into the aliases expected<T, E>, outcome<T>, result<T>, option<T>. They are all the same class and object, just with policy-determined "personality" that lets them provide differing semantics to each user, yet they all still operate seamlessly together and can be fed into one another e.g. via the TRY operation, and with very low, usually minimum, runtime overhead and low compile time overhead. If you are only in the market for just an expected<T, E> implementation and nothing else, then yes Outcome looks over engineered. But my claim is that in any real world code base of any size, people end up having to add layers on top of expected<T, E> etc to aid interop between parts of a large code base. They will have varying degrees of success, as people on Reddit have told me regarding their local expected<T, E> implementations. A lot of people end up with macros containing switch or try catch statements to map between differing error handling systems. And that is bad design. I will claim that if you *are* building such an interop framework, you will find that Outcome is the bare minimum implementation possible. It is, if anything, *under* engineered compared to the many other "universal error handling frameworks for C++" out there which tend to throw memory allocation and smart pointers and type erasure at the problem. Outcome doesn't do any of that, it never allocates memory, has highly predictable latency, runs perfectly with C++ exceptions disabled, is an excellent neighbour to all other C++ libraries AND build systems, and avoids where possible imposing any constraints on the user supplied types fed to it. It also lets you use as much or as little of itself as you choose. So okay, it's over engineered if you think you want just an expected<T, E>. But as soon as you roll expected<T, E> out into your code, you are going to find it won't be enough. Thus the rest of Outcome comes into play, and even then there are small gaps in what Outcome provides which any real world application will still need to fill. That's deliberate *under* engineering, I couldn't decide on what was best for everyone, so I give the end user the choice by providing many customisation points and macro hooks. I'll respond to your other comments in a separate reply. I just needed to unload the above, and I appreciate that the docs do not sufficiently get into the universal error handling framework part of Outcome. That is due to repeated Reddit feedback telling me that earlier editions of the docs didn't make sense, and I needed to go much slower and hold the hand, so you got the current tutorial which as you've already observed, is too long as it is. It would become even longer if you started dissecting universal error handling strategies. (And my thanks to Andrzej for the motivating example on the landing page of the docs, he did a great job capturing the universal error handling framework aspect of Outcome. I would love to know if reviewers can make sense of it, or did it just confuse the hell out of everybody) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/