Re: [boost] [outcome v2] Please comment on new result<T, EC> reference API docs

Subject: Re: [boost] [outcome v2] Please comment on new result<T, EC> reference API docs
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-22 23:51:43

On 23/06/2017 00:00, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
> 
>> I appreciate that this change is controversial. However, I am also
>> minded that there is no point in Outcome v2 covering the identical
>> ground as Expected, just less well.
> 
> Can't say I agree with that. Outcome should cover the ground that needs
> to be covered. Not cover useless ground that nobody needs covered
> (status) just to avoid the "expected" ground. If that makes result<T,
> EC> virtually identical to expected<T, E>, so be it. This is just a sign
> that both you and Vicente have the basic design correct. You will still
> differentiate based on implementation quality, extra features of
> error_code_extended, and the added value that outcome brings to the party.

I appreciate this.

However I am thinking here in terms of WG21 standardisation,
specifically SG14's work on a std::vector upgrade which doesn't have the
really unfortunate unpredictable latency. The general idea is that a low
latency std::vector would never expand its capacity automatically,
instead it would return success + capacity approaching warning status.
You then could schedule the construction of a new, bigger vector outside
the hot path.

That's why Lawrence's Status + Value proposal garnered such interest,
but there were concerns about whether an expected<T, E> type solution
like Outcome v1 would be a better approach instead, so the idea was that
expected<T, please_reallocate<T>> could be returned. I don't much care
for that idea personally, but it has its fans.

I am dropping the expected<T, E> implementation from Outcome v2. That
will lose me a ton of user base. I am minded to claw some of that back
from elsewhere, perhaps solve some other pressing problems for SG14
around the Status + Value need. It costs me almost nothing in terms of
implementation, so a bit like with empty state, I am minded to provide
it opt-in. We'll see how it goes.

Niall

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