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

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 }

or

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

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