Subject: Re: [boost] [outcome] How to write a review considering the broad scope
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-26 16:52:45
>> 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.
> 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
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk