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

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 // + some global functions void f(const global &g){ do something } or template<class T> struct outcome : public std::variant { // 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 using outcome = V 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