2017-06-02 12:09 GMT+02:00 Niall Douglas via Boost
But this isn't really my point. The point I'm trying to make is that all the design disputes are also found in variant. It would seem to me that we're repeating all the same arguments ... with pretty much similar results. If the problem is that variant (std, boost, ...) is "broken" or not suitable for that reason it would seem to me that THAT problem would need to be addressed. Were that the case, then all the issues with outcome, optional, result, expected would disappear. Maybe I'm over simplifying here, so feel free to demonstrate I'm wrong. In any case, I would think that if a consensus can't be agreed upon after all this effort, maybe we should step back and except as a fact that "concensus cannot be reached". So we'll permit variant implementations of variant either with policy or simpler yet, just a separate implementation. Of course these separate implementations would also share a common base class so we get nested russian dolls. But at least we don't get so much repetition.
There is one big difference with std::optional and std::variant - their design is now **the standard**, for better or for worse.
All new code written henceforth ought to be designed around the C++ standard in my book, with hacks/workarounds as appropriate where the standard object falls short.
But otherwise regarding discussion of Outcome, I think there are three main use patterns for failure returning objects, and a single object design can't fulfill more than two of them at best.
You have never put it this way. Can you list the three use patterns here? Regards, &rzej;