Boost logo

Boost :

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-01 17:43:33

On 6/1/17 10:24 AM, Vicente J. Botet Escriba via Boost wrote:
> The problem is that we don't have a never-empty variant in Boost (we
> have Boost.Variant, but it uses double buffer IIRC).
> Vicente

Right - so isn't variant the place to "fix" it? if outcome, expected,
optional ... need a never-empty guarantee, should variant (std, boost,
whatever) have that guarantee as well? Shouldn't these discussions take
place in the context of variant?

Now if the "best" implementation of variant isn't the "best" one for one
of it's derivatives - then I would ask why not? How are they different.
  Of course this can windup as variant having a policy. I haven't seen
this but I would be very surprised if it hasn't come up. In any case it
seems that it would be much more efficient for these types to derive
from variant then repeat implementations - each with a little different
sauce. Not only more efficient as in reducing code. But more efficient
in consumption of my limited brain power:

OK I understand variant, never empty or not, etc...

template<class T>
using outcome = std::variant<T, std::error_code>

// + some global functions void f(const global &g){ do something }


template<class T>
struct outcome : public std::variant<T, std::error_code> {
// some special member functions
        outcome(const std::error_code & e){...} // construct as error
        outcome(const T & t){...} // construct legitimate result

(I'm obviously winging it here as I don't remember exactly what outcome

Basically, I'm arguing that all the discussion/design of these
"derivative" types belong in variant. Of course if there is not
agreement (not that this would ever happen) one could

template<class T, class V = std::variant>
using outcome = V<T, std::error_code>

In any case, I would be factoring out common code, design, rationale,
maintenance problems, documentation, etc up into the base class variant.

FWIW - this was my concern when I saw your presentation a few years ago.
  Not that it was without merit, but I saw it as more of a use case for
variant rather than a new library component.

Robert Ramey

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