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

Niall Douglas wrote:

...

My original idea was to implement my idea of expected, but I took a detour through never-valueless variant<> first.

Would you be intending to submit your variant2 into Boost, along with an expected 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 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.