Am 08.10.20 um 12:51 schrieb Benedek Thaler via Boost:
Thanks to all of you who participated in the formal review of PFR, henceforth known as Boost.PFR, and Antony Polukhin for submitting this magical library.
PFR is ACCEPTed into Boost, with the following results:
ACCEPT: 5 votes CONDITIONAL ACCEPT: 1 vote REJECT: 0 votes
Reviewers highlighted that the library is "very useful", "magical" and "provides a form of reflection in a simpler manner than other solutions thus far".
During the review, several points of improvements were identified, and Antony committed to improve the library accordingly. The main concerns were:
- Definition of the type concept the library can work with - Clarification of the flat / precise use-cases - The presence of global operators - The way output formatting is defined - Dropping "Reflection" from the name (this is already reflected in the docs)
Antony plans to:
- Remove Flat reflection - Remove global_ops - Add more examples to the docs, introduce terms in a cleaner manner - Improve the reference section - Take another look at the pfr::ops and macro for operators
After all these changes have been implemented, Antony would really like to have a mini-review, regardless that the library is already ACCEPTed, further confirming his high standards.
Good luck Antony, keep up the good work!
Congratulations on the acceptance and thanks to Benedek for managing the review. As a mini-review is requested to be done later I'd like to highlight one important point that I distilled from the discussions during the review (I didn't participate though): IMO one of the most important things that is expected from Boost is that the stuff either works as expected in all situations (compilers, platforms, ...) or clearly errors out at compile time. I'd hence like to encourage work/evaluation during the improvement phase to focus on this aspect. Removal of the "flat" part, which seems to be the most problematic, is a good step. Same as global_ops which could cause ODR issues. So all in all explicit opt-in to ops even at the cost of some boilerplate is better than "maybe" breaking stuff in very unexpected ways (ODR issues are a nightmare) and I'd rather see a stripped down, more complex, boiler-platy interface for the first release and carefully improve on that later, than trying to hard to have everything and missing a corner case. Again thanks @ Antony for the library and your dedication to polish it up to those high standards that are expected from Boost as well as pushing the boundaries of C++, which has always been the essence of Boost. Regards, Alex