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

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

Niall

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