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

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-01 22:02:55

>> Hmm, maybe you could also implement expected<T, E>, and that would
>> kinda eliminate the need for a Boost.Outcome?
> 
> 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.

I'll still be implementing my agreed changes to my own Outcome as lots
of my code depends on my specific formulation, and I don't want a Boost
dependency anyway. But most of the work of getting a Boost library past
review is not implementing and testing a high quality implementation,
it's all the other stuff like endless documentation and indeed, writing
300+ emails as part of a two week long review.

If I could skip all that other stuff because you were taking it on, I'd
be **overjoyed**. I could get back to working on AFIO v2 instead, a big
gain for me.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/