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.