[review] Review of Outcome (ends Sun-28-May)
Hi, Everyone, First a (very-)big "thank-you!" to all participating in the ongoing (and vigorous) debate and review for the Outcome library. The spirited discussion touches on tricky issues for composition and error handling (with and without C++ exceptions enabled), where the community is clearly searching for best convention and common ground. Thus far: (a)- some 300+ emails discussing Outcome (and more emails off-list) (b)- participation from: *- Andrzej Krzemienski *- D25fe0be *- Deniz Bahadir *- Emil Dotchevski *- Gavin Lambert *- Glen Fernandes *- Gottlob Frege (Tony) *- Hartmut Kaiser *- Ion Gaztanaga *- Jonathan Muller *- Niall Douglas *- Paul Bristow *- Pete Bartlett *- Peter Dimov *- Robert Ramey *- Thomas Heller *- Vicente J. Botet Escriba *- Vinnie Falco *- ...(apologies if I've missed anyone) (c)- Some points-of-discussion relate to: *- Outcome efficiency (copy/move) on today’s compilers *- Outcome speed/overhead (exceptions) *- Outcome purpose/motivation *- Outcome Tutorials, documentation *- Outcome “formal-empty-state”, default-initialization *- Outcome compiling, compiler support *- Outcome ABI, namespace usage, use of preprocessor *- Outcome alternative APIs *- std::expected proposal, possible changes (d)- Reviews to date (sent publicly to the list): *- Paul Bristow -- accept, conditional (Tue-23-May) *- Deniz Bahadir -- accept, unconditional (Wed-24-May) *- Thomas Heller -- (almost a review), ?reject, "not-ready-yet?" (Wed-24-May) (e)- Significant other discussion also contributes to evaluation of Outcome as a Boost library. However, I encourage further reviews to make clear any conclusions from these discussions that I might have missed. The review continues for several more days, ending Sun-28-May. Please consider posting a review to the boost mailing list, or privately to the Review Manager (to me). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley
Charley, Any chance to extend the review period. I intend to write a review. But it is really time consuming. And all the discussions, fruitful as they are, distract me from the task. Regards, &rzej; 2017-05-26 0:43 GMT+02:00 charleyb123 . via Boost <boost@lists.boost.org>:
Hi, Everyone,
First a (very-)big "thank-you!" to all participating in the ongoing (and vigorous) debate and review for the Outcome library. The spirited discussion touches on tricky issues for composition and error handling (with and without C++ exceptions enabled), where the community is clearly searching for best convention and common ground.
Thus far:
(a)- some 300+ emails discussing Outcome (and more emails off-list)
(b)- participation from:
*- Andrzej Krzemienski *- D25fe0be *- Deniz Bahadir *- Emil Dotchevski *- Gavin Lambert *- Glen Fernandes *- Gottlob Frege (Tony) *- Hartmut Kaiser *- Ion Gaztanaga *- Jonathan Muller *- Niall Douglas *- Paul Bristow *- Pete Bartlett *- Peter Dimov *- Robert Ramey *- Thomas Heller *- Vicente J. Botet Escriba *- Vinnie Falco *- ...(apologies if I've missed anyone)
(c)- Some points-of-discussion relate to:
*- Outcome efficiency (copy/move) on today’s compilers *- Outcome speed/overhead (exceptions) *- Outcome purpose/motivation *- Outcome Tutorials, documentation *- Outcome “formal-empty-state”, default-initialization *- Outcome compiling, compiler support *- Outcome ABI, namespace usage, use of preprocessor *- Outcome alternative APIs *- std::expected proposal, possible changes
(d)- Reviews to date (sent publicly to the list):
*- Paul Bristow -- accept, conditional (Tue-23-May) *- Deniz Bahadir -- accept, unconditional (Wed-24-May) *- Thomas Heller -- (almost a review), ?reject, "not-ready-yet?" (Wed-24-May)
(e)- Significant other discussion also contributes to evaluation of Outcome as a Boost library. However, I encourage further reviews to make clear any conclusions from these discussions that I might have missed.
The review continues for several more days, ending Sun-28-May. Please consider posting a review to the boost mailing list, or privately to the Review Manager (to me). Here are some questions you might want to answer in your review:
- What is your evaluation of the design?
- What is your evaluation of the implementation?
- What is your evaluation of the documentation?
- What is your evaluation of the potential usefulness of the library?
- Did you try to use the library? With what compiler? Did you have any problems?
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
- Are you knowledgeable about the problem domain?
And most importantly:
- Do you think the library should be accepted as a Boost library?
For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html
Thank you very much for your time and efforts.
--charley
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 26/05/2017 10:51, Andrzej Krzemienski wrote:
Any chance to extend the review period. I intend to write a review. But it is really time consuming. And all the discussions, fruitful as they are, distract me from the task.
+1 for a hope to extend the review period. Even getting a bit of a head start on discussion about the library, there are still things to discuss and I think that discussion is useful. And once consensus is reached (or perhaps not) it could impact peoples' opinions for their review.
Any chance to extend the review period. I intend to write a review. But it is really time consuming. And all the discussions, fruitful as they are, distract me from the task.
+1 for a hope to extend the review period. Even getting a bit of a head start on discussion about the library, there are still things to discuss and I think that discussion is useful. And once consensus is reached (or perhaps not) it could impact peoples' opinions for their review.
I have no objection, but be aware my final written exam for my Maths degree is on the 9th June, and I'll need to start rehearsing past papers soon. So I wouldn't be as timely with my replies as at present. That said, you're probably safe till 2nd June. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
<snip>, The 'Outcome' review continues for several more days, ending Sun-28-May.
On 26/05/2017 10:51, Andrzej Krzemienski wrote:
Any chance to extend the review period. I intend to write a review. But it is really time consuming. And all the discussions, fruitful as they are, distract me from the task.
On Thu, May 25, 2017 at 6:03 PM, Gavin Lambert via Boost <
boost@lists.boost.org> wrote:
+1 for a hope to extend the review period. Even getting a bit of a head start on discussion about the library, there are still things to discuss and I think that discussion is useful. And once consensus is reached (or perhaps not) it could impact peoples' opinions for their review.
After off-list discussion with the Review Wizards, the Outcome review period is extended to June 2. *- For more information about the Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Again, thank you all (very!) much for the high level of considered opinion and active involvement in this review, as some of the topics are clearly large or tricky. --charley
(a)- some 300+ emails discussing Outcome (and more emails off-list)
My current count is 361 publicly posted emails. As a comparison, the AFIO v1 review came in just over 500, and this one has been on a much, much smaller library with what one would think much fewer design permutations. Thank you everyone. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 05/26/2017 12:43 AM, charleyb123 . via Boost wrote:
*- Thomas Heller -- (almost a review), ?reject, "not-ready-yet?"
Please don't count my comments as a review. I don't feel qualified right now to make any statements on the quality of the library presented. There is too much in flux of it right now and after all discussions, it is not clear to me what the current state of the library really is and how much it will change after the review. -- Thomas Heller Friedrich-Alexander-Universität Erlangen-Nürnberg Department Informatik - Lehrstuhl Rechnerarchitektur Martensstr. 3 91058 Erlangen Tel.: 09131/85-27018 Fax: 09131/85-27912 Email: thomas.heller@cs.fau.de
2017-05-26 8:34 GMT+02:00 Thomas Heller via Boost <boost@lists.boost.org>:
On 05/26/2017 12:43 AM, charleyb123 . via Boost wrote:
*- Thomas Heller -- (almost a review), ?reject, "not-ready-yet?"
Please don't count my comments as a review. I don't feel qualified right now to make any statements on the quality of the library presented. There is too much in flux of it right now and after all discussions, it is not clear to me what the current state of the library really is and how much it will change after the review.
You are making a valid point. Typically, the outcome of a boost review is etiher "accept" or "acceppt, but fix this and that", or "reject". Now, during this review, my feeling is we are just trying to design big parts of the library. There is so many open questions, that one cannot get te sense of the final shape. To reject it would be sending the wrong message that we do not wat the problem to be solved, or that the solution is wrong. But it is not wrong: it is just "I can make it whatever you want". To accept it on condition that it has a different interface, is like accepting something else than what we see. We can do it technically, but it feels wrong. I am confused here, I admit. Regards, &rzej;
On 05/26/2017 12:43 AM, charleyb123 . via Boost wrote:
*- Thomas Heller -- (almost a review), ?reject, "not-ready-yet?"
Please don't count my comments as a review. I don't feel qualified right now to make any statements on the quality of the library presented. There is too much in flux of it right now and after all discussions, it is not clear to me what the current state of the library really is and how much it will change after the review.
You are making a valid point. Typically, the outcome of a boost review is etiher "accept" or "acceppt, but fix this and that", or "reject". Now, during this review, my feeling is we are just trying to design big parts of the library. There is so many open questions, that one cannot get te sense of the final shape. To reject it would be sending the wrong message that we do not wat the problem to be solved, or that the solution is wrong. But it is not wrong: it is just "I can make it whatever you want". To accept it on condition that it has a different interface, is like accepting something else than what we see. We can do it technically, but it feels wrong. I am confused here, I admit.
We have had such situations before, IIRC. The Boost Serialization library for instance was rejected twice (!) before being accepted in the end because the reviews ended up in a similar state (too many open design questions). Generally, I don't think that rejecting a library sends a wrong message. It just means that it is not ready yet (for whatever reason, not necessarily because of bad quality or similar). I for myself don't feel I'd be able to judge the library at this point as it is not even clear anymore what we're reviewing... and I'm sure others feel the same. But I would feel bad if the library got accepted now just because people feel it would 'send a wrong message' otherwise. For this reason I would like to suggest for the review manager to consider re-scheduling the review to a date after the results of the discussion have been incorporated, without making an acceptance decision right now. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Typically, the outcome of a boost review is etiher "accept" or "acceppt, but fix this and that", or "reject". Now, during this review, my feeling is we are just trying to design big parts of the library. There is so many open questions, that one cannot get te sense of the final shape. To reject it would be sending the wrong message that we do not wat the problem to be solved, or that the solution is wrong. But it is not wrong: it is just "I can make it whatever you want". To accept it on condition that it has a different interface, is like accepting something else than what we see. We can do it technically, but it feels wrong. I am confused here, I admit.
This review is surely exactly like any normal review! Before giving your review, you would: 1. Read the changes already implemented to develop branch at https://github.com/ned14/boost.outcome/blob/develop/doc/md/08-changelog.md 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 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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Le 26/05/2017 à 16:31, Niall Douglas via Boost a écrit :
Typically, the outcome of a boost review is etiher "accept" or "acceppt, but fix this and that", or "reject". Now, during this review, my feeling is we are just trying to design big parts of the library. There is so many open questions, that one cannot get te sense of the final shape. To reject it would be sending the wrong message that we do not wat the problem to be solved, or that the solution is wrong. But it is not wrong: it is just "I can make it whatever you want". To accept it on condition that it has a different interface, is like accepting something else than what we see. We can do it technically, but it feels wrong. I am confused here, I admit. This review is surely exactly like any normal review!
Before giving your review, you would:
1. Read the changes already implemented to develop branch at https://github.com/ned14/boost.outcome/blob/develop/doc/md/08-changelog.md
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. 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?
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. In the committee we do some straw-pools (SF, F, N, SA, SA), but this is more complex when we are not in face to face. If I was you I will try it for some of important points. Best, Vicente
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-tp4... 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/
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-tp4...
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
Le 26/05/2017 à 18:52, Niall Douglas via Boost a écrit : 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
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<T, E>`, `outcome<T>` and `result<T>`, but he will provide a "secret API" that normal programmers will never know about, but people like me and you, who have participated in all these discussions, and learned about it, may of curiosity quite easily build a new type of `expected` and experiment with it, and have useful feedback to LWG about practical consequences of different design decisions. Niall, did I got your idea correctly?
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
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<T, E>`, `outcome<T>` and `result<T>`, but he will provide a "secret API" that normal programmers will never know about, but people like me and you, who have participated in all these discussions, and learned about it, may of curiosity quite easily build a new type of `expected` and experiment with it, and have useful feedback to LWG about practical consequences of different design decisions.
Niall, did I got your idea correctly?
Exactly correct. I am currently preparing a "high level summary" of Outcome after all the changes I've agreed to, to help refine and focus further discussion of whether to accept or reject the library. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 5/26/17 15:49, Niall Douglas via Boost wrote:
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<T, E>`, `outcome<T>` and `result<T>`, but he will provide a "secret API" that normal programmers will never know about, but people like me and you, who have participated in all these discussions, and learned about it, may of curiosity quite easily build a new type of `expected` and experiment with it, and have useful feedback to LWG about practical consequences of different design decisions.
Niall, did I got your idea correctly?
Exactly correct.
I am currently preparing a "high level summary" of Outcome after all the changes I've agreed to, to help refine and focus further discussion of whether to accept or reject the library.
Niall
+1 ... Thank you Niall! -- Michael Caisse Ciere Consulting ciere.com
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:
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<T, E>`, `outcome<T>` and `result<T>`, but he will provide a "secret API" that normal programmers will never know about, but people like me and you, who have participated in all these discussions, and learned about it, may of curiosity quite easily build a new type of `expected` and experiment with it, and have useful feedback to LWG about practical consequences of different design decisions. If the library will provide a generic class that support I don't remember how many combinations I will against its acceptation. I have not see too much people adhering to the design Niall proposed in
Le 26/05/2017 à 23:13, Andrzej Krzemienski via Boost a écrit : the previous link, quite we can deduce the opposite from the comments. But maybe it si my bad and people want this hyper-generic design. I would start a straw-pool here Who is strongly for, for , neutral, against, strongly against] the design of the generic class presented by Niall in http://boost.2283326.n4.nabble.com/outcome-Ternary-logic-need-an-example-tp4... In fact, I am increasingly thinking that a consensus position could be this type factory template: // What to default construct to enum class default_to { none, T, EC, E }; // How much empty state to implement enum class emptiness { never, // imposes restrictions on T, EC, E formal, // formal empty state tolerant // empty state iff EC and E don't have nothrow move construction }; // How narrow or wide the observers will be enum class observers { narrow, // accessing not the current state = reinterpret_cast wide, // default actions already described earlier this review single_shot // you can observe state precisely once only }; // Replacement for basic_monad template< class T, // what .value() returns, or void class EC, // what .error() returns, or void class E, // what .exception() returns, or void default_to default_to_config, emptiness empty_config, observers observers_config
class outcome_impl;
// Outcome as apparently desired by reviewers template<class T> using outcome = outcome_impl< T, error_code_extended, std::exception_ptr, default_to::none, // default constructed instance = reinterpret_cast uninitialised memory emptiness::never, // Never possible to be empty, not ever observers::narrow // reinterpret_cast all observers
;
// Result as apparently desired by reviewers template<class T> using result = outcome_impl< T, error_code_extended, void, // there is still a .exception(), but it returns void and is not usable default_to::none, // default constructed instance = reinterpret_cast uninitialised memory emptiness::never, // Never possible to be empty, not ever observers::narrow // reinterpret_cast all observers
;
[SF F N A SA] I'm SA for the reasons described in linked thread. Best, Vicente
participants (8)
-
Andrzej Krzemienski -
charleyb123 . -
Gavin Lambert -
Hartmut Kaiser -
Michael Caisse -
Niall Douglas -
Thomas Heller -
Vicente J. Botet Escriba