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-23 01:13:29

>> 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.
> 
> I find this example as unconvincing as Lawrence's original one. For one,
> vector functions that grow the size typically return void. So you could
> just turn that into bool or an enum and you'd be done.
> 
> For another, when you're in the hot path, the "capacity warning" status
> is not actionable, so it's of little use. Instead, when you get out of
> the hot path (or, better yet, before you get into it), you'd simply
> check capacity(), see if it's yellow/red, and reserve. Or not even
> check, just reserve( size() + <hot path max size requirement> ).

All valid observations.

Yet SG14 likes anything which relocates latency unpredictable things
(exception throws, malloc, etc) to the caller. It's certainly how I'd
have personally designed the STL originally. std::vector's latency
insensitive design has always irritated me, and I still hope - without
much basis - that any STL v2 will fix that.

I'm minded to try and deliver SG14 a vocabulary type which can help with
that so they can propose it for standardisation. As much as it'll cause
problems with the Boost review, it delights SG14 members. I received
quite a lot of private email during and after the Outcome v1 review
about how from the review feedback on boost-dev it was clear here
doesn't understand SG14's needs and priorities. I really wish they'd say
that here instead of emailing me privately about it. I already know,
it's a difference of mindset and philosophy.

Niall

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