Re: [PFR][review] Result

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2020-10-08 11:51:13

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