Boost logo

Boost :

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-02 10:09:15


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

I personally believe that "single implementation, multiple
personalities" solves the problem, but I recognise that I have failed to
persuade anyone of that during this review, which was a surprise to me
actually. But finding out what others really care about, and you had no
idea that they did, is the whole point of a successful Boost review
irrespective of outcome.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk