*- 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.htmlThank you very much for your time and efforts.
--charley