So looking a few of these libraries/proposals I have a few things I'm interested in. - Is it at least as good as a simple hand-rolled solution? - Can you transport error codes through layers without knowing specifics of an error? For the second Niall's outcome/result handles very well I think. std::error_code and std::exception_ptr transport is good enough for almost any reasonable type agnostic error transport. If the direct caller can handle the error returning an error enum instead of a std::error_code will often be better. It looks like the DXXXXR0 expected proposal allows for this. A variant is a good implementation for many types. And I think clearly the right default behavior. However, I'm not convinced that a variant is always the best implementation. Take for example an expected<void*,error_enum>. Although I haven't done tests I'd be reasonable confident returning this by value would perform worse than returning std::pair<void*,error_enum>. First, the machinery is going to make it store an extra byte at least for the variant discriminator. Then, you likely branch before the copy (maybe optimized away by a smart variant implementation). In fact in *most* cases of returning a pointer and error_enum you should be able to get away with returning a the equivalent of union { void*, error_enum } As *most* error_enums are relatively small and have values smaller than any valid heap or stack pointer. It would be nice to be able to opt in for this. More generally given - an error_enum with an OK or 'not an error' value - a T that is cheap to default construct and cheap to copy/move Is the library solution better than returning a pair<T, error_enum>? Or a function returning an error_enum with an out param?