Subject: Re: [boost] [outcome] How to write a review considering the broad scope
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-26 20:58:29
Le 26/05/2017 Ã 18:52, Niall Douglas via Boost a Ã©crit :
>>> 2. Read the changes I've accepted from peer review feedback at
>>> 3. If you like the library after all those issues were implemented,
>>> recommend acceptance, possibly conditional on further things you
>>> personally think need to be changed yet.
>>> 4. If you dislike the library after all those issues were implemented,
>>> recommend rejection, preferably with a list of what should be in the
>>> library instead. Nobody wants a flawed design in Boost, myself included.
>> The issue list don't tell us what will be done.
> If any of the issues are insufficiently specified for you to make a
> review recommendation, please do say which and I will expand their
> I would say that I think it very highly likely I'll be implementing my
> proposed typedef factory API at:
> That way everybody gets the Outcome they want. I will of course typedef
> outcome<T> and result<T> to whatever the consensus recommendation is
> from here, but say if Peter really wants the default constructor to make
> a singular empty state, he gets that. If I want a totally unavailable
> default constructor, I get that. And so on.
This will clarify my review. If after all the discussion you find that
this is the way to go, clearly I'll not support you.
>> I would like to have your opinion on what Boost.Outcome should become
>> after the exchanges we have had and before been accepted.
>> Which Boost.Outcome library you would like to have in Boost?
> My opinion is still forming. You have persuaded me just recently
> regarding default constructors for example.
>>> The review manager is ultimately the person who decides based on
>>> everyone's reviews. Your review is there to help them decide. I
>>> certainly wouldn't worry about recommending rejection if you think the
>>> presented design + fixes in the issues would result in a library you
>>> don't want to see in Boost.
>> If you believe we should have a review after everything has been updated
>> your decision is more important than the one of the review manager.
>> We need however to have a sort of consensus of what we want at the end.
> Well, actually no for Outcome. You are right regarding Expected, that
> ought to be a consensus decided design. But Outcome is my personal
> vision on what ought to be supplied in **addition** to the consensus
> decided Expected design.
> After all, if I didn't have a personal vision there, then Outcome would
> solely supply an Expected implementation and nothing else because by
> definition there is no such thing as *two* consensus designs.
> The changelog and the issues list reflect everything I've decided to fix
> or change in the Outcome library presented to you for review. I am still
> adding to the issues list in particular, but whatever it ends up at at
> the end of this review IS my opinion on how Outcome would be if accepted
> into Boost.
This will clarify my review also.
At the end it is up to you to decide what Outcome will be.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk