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

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Peter Dimov (lists_at_[hidden])
Date: 2017-06-01 22:54:02

Niall Douglas wrote:
> > My original idea was to implement my idea of expected<T, E...>, but I 
> > took a detour through never-valueless variant<> first.
>
> Would you be intending to submit your variant2 into Boost, along with an 
> expected<T, E...> implementation sometime soon?

We'll see.

> You see, from my perspective, getting Outcome into Boost is nothing like 
> as important as getting **any** sort of variant-stored result<T> type 
> thing into Boost. I need one of those into Boost to make getting AFIO v2 
> into Boost feasible as every single AFIO API returns a result<T>.
>
> In other words Peter, if you'd like to do the heavy lifting getting your 
> own Outcome implementation extending Variant2 into Boost instead of me ... 
> I'm all for it.

That's not and hasn't been my intention.

I wanted to write expected<T, E...> so that we have something concrete to 
discuss regarding standardization, and for that, I needed a never-valueless 
variant, which is also something that I would rather see in the standard at 
some point, preferably instead of the current one.

The result and outcome classes I threw together are only toys at this point, 
their purpose is both to let us see how the compilers optimize, and for me 
to demonstrate how I would like the interface of 
boost::result/boost::outcome/std::result/std::outcome to look like.

But I don't really want to enter these implementations in Boost instead of 
yours. Your implementation has been tested in practice and is more 
feature-rich. The error_code_extended infrastructure adds significant value, 
and if you agree to a larger (or customizable at runtime) ring buffer and 
chaining support, they'll become even better. (Attaching information to an 
error code is a very good idea of yours.)

In short, I'd rather see your implementations in Boost, but with something 
close to the interface I present - if the community can agree on it, of 
course.

It's just hard to keep the design discussion focused without a reference 
implementation. Ideally, we all say at some point OK, we're fine with that 
interface, this is it, there we go.