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/