On 25/05/2017 08:44, Jonathan Müller wrote:
What about providing no default constructor? There are two valid choices so why surprise half the users?
Yes, it makes it a bit harder to use in arrays, but how often would it need to be stored in arrays anyways.
Surprisingly often, if it ends up being used to represent the collection of results from methods executed in sequence or in parallel (although perhaps future<> is more suited to that task, since they're more likely to be asynchronous). Speaking of which, it seems like outcome<> is essentially just trying to be a not-asynchronous version of future<> that can elect to transport a std::error_code instead of a std::exception_ptr. So most likely its design decisions should be inspired mostly from that (and any pain points that people have experienced with that interface). Perhaps it even should be designed in such a way that std::future itself could be based on it?