2017-05-26 22:58 GMT+02:00 Vicente J. Botet Escriba via Boost < boost@lists.boost.org>:
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 think what Niall is saying here is that In the public API, you will get
`expected
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost