Boost logo

Boost :

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at