extend glaze explicit reflection with private members

[schaumb]

extend glaze explicit reflection with private members

[stephenberry]

I think this is an awesome approach, thanks for all your work on this! I'm planning to add support once some other features and fixes are completed, or I would be happy to merge a pull request.

I do think it would be a good idea to add a compile time option to disable private access for those who do not want it (or deem it dangerous). I think once the feature is implemented it will be more obvious where this should go.

[stephenberry]

@schaumb, I'm sure you've seen this post about a C++20 approach to private access: https://dfrib.github.io/a-foliage-of-folly/

I like how this approach does not use the stateful meta programming (tag approach). I'm curious what you think about this approach.

I experimented with private access support and I've decided to hold back from including it in Glaze directly. Libraries like yours can be used with Glaze (lambda wrappers in glz::meta are one approach), to expose private variables where needed.

Adding support directly within Glaze would reduce boilerplate, but it would make it so clean that I feel uncomfortable bypassing an intended design feature of C++. It is better to encourage users to use public APIs, accessors, and other intended design features normally.

I do think accessing private members is fantastic for certain use cases, such as third party library serialization, and for debugging. But, realizing that I could just bring in a library like yours and use it with Glaze makes me less inclined to add it here.

Thanks for your research and work into this!

[schaumb]

Thanks for the link @stephenberry !

I didn't know this article before. The main concept behind my access_private_20 project is that no macros are needed for the members (unlike the original access_private and the linked accessprivate), and the interface is unified to one definition: access_private::access<MPTR> (no const diff, etc).

These are impossible without the friend injection, or the name duplication (pre/post function declaration).

[stephenberry]

Makes sense, I really like your implementation and it being macro free. Your approach should get even cleaner when we get reflection in C++.