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