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?
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk