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: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-26 07:48:08

2017-06-23 3:13 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> >> 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.
>

A superior alternative to vector? -- ok, but this is not clear how the
"value + status" vocabulary type helps here. It is not enough to say, I can
return two things. You would also have to demonstrate, how users will work
with such status value: if it is even possible, without compromising the
clarity of the code.

> 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.
>

So, let's summarize what you are saying here:
1. Your goal is to service "SG14 people".
2. "SG14 people" do not trust Boost community could understand/appreciate
their needs to the extent that they do not even offer their input during
the review.
3. You want this library for "SG14 people" to go through Boost review, and
become part of Boost.

Maybe this is a wrong way to go, because what you will hear here is, "not
well justified", "no demonstrated use cases that would be improved by your
library".

Alternatively, what you could do, given the fact that "SG14 people" refuse
to give their input in boost-dev, is to act like a proxy and convey their
arguments here. But so far, you have been only conveying the "I need this"
part, not the really interesting part: "when I have it I can do this". In
the other message you showed us how a vector with capacity fixed upon
construction is better than `std::vector`, but it didn't illustrate why
there is a need for a "value + status" type. I realize my expectations must
be frustrating. On the other hand, without it, I do not see how people in
boost-dev can fulfill their task of giving you a valuable feedback.

Regards,
&rzej;