-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make pfr more friendly for integrating into other libraries? #100
Comments
What further prospects will we get if we implement this approach:
|
I'd appreciate help with all the above points |
I wrote a draft code for this functionality. The whole PR with docs and tests will be in a nearest future. I suppose that these changes will be super clean and won't get stuck on review. Draft: https://godbolt.org/z/Y98xhajb8 Not all of the planned was done, some points turned out to be impracticable (and inexpedient), I will describe in more detail about deviations from the plan in the PR. How can we use modified PFR to make other libraries extensions? Like these: Also, i want to say that the most difficult part of the future PR is the implementation of |
We decided to select yet more simple strategy for integrating. In the Fusion side PFR will be fallback, and will be selected when no other reflection not found for T. It can be solved using Draft: https://godbolt.org/z/P1481orTM The whole PR in progress, also sample for Fusion and Spirit. It all will be available in the nearest future. |
We also need to apply patch on the Fusion side, described here: boostorg/fusion#231 |
Look at this: #111 |
Looks like everything is done here. Closing. Please create new issue if there's anything to improve |
Description of issue
Now i'm working with Boost.Fusion extension for Boost.PFR, i decomposed it into 3 PR's and opened these PR's here: boostorg/fusion#241, here boostorg/fusion#242 and here boostorg/fusion#243.
Review is moving on, there is some wishes from reviewers(more on that later).
First, I would like to talk about such a problem like 3 PR's is too much code and the review takes too long.
I suggest to make pfr more adaptable and more friendly to adapt into other libraries(not only fusion).
Suggested solution
boost::pfr::view
boost::pfr::view_fields
BOOST_PFR_REGISTRATE_REFLECTABLE
macro.boost::pfr::is_reflectable
trait. Example of using trait:boost::pfr::is_reflectable
trait for create overloading of compare/io operators and specialization ofstd::hash
function. Examples of using these overloads:io
,eq
,ne
,lt
,gt
,le
,ge
,hash_value
,io_fields
,eq_fields
,ne_fields
,lt_fields
,gt_fields
,le_fields
,ge_fields
,hash_fields
,BOOST_PFR_FUNCTIONS_FOR
as deprecated, and to actualize https://www.boost.org/doc/libs/1_75_0/doc/html/boost_pfr/tutorial.html#boost_pfr.tutorial.three_ways_of_getting_operators.Conclusion
If everything planned can be done, then the PFR will be adapted as easily as the
std::tuple
, it will be just one small PR.The text was updated successfully, but these errors were encountered: