Re: [boost] [outcome] To variant, or not to variant?

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-02 10:36:12

2017-06-02 12:09 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> > 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;