Re: [boost] [outcome] How to write a review considering the broad scope

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
>>> https://github.com/ned14/boost.outcome/issues
>>>
>>> 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
> description.
>
> I would say that I think it very highly likely I'll be implementing my
> proposed typedef factory API at:
>
> http://boost.2283326.n4.nabble.com/outcome-Ternary-logic-need-an-example-tp4694199p4694620.html
>
> 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.

Best,
Vicente