Integrating with boost::pfr?

[schaumb]

The recent pfr update introduces a new feature allowing the retrieval of aggregated object member names.
This enhancement enables the parsing and serialization of aggregate object types without the need for macros or defined functions, directly accessing the members and their names.

(For potential concerns or limitations, please refer to the caveats.)

Your thoughts on this development would be appreciated.

[grisumbras]

If I unterstand the issue correctly, this is about conversions. From the cursory look, such feature can be a part ofBoost.PFR. PFR doesn't even have to add a physical dependency on JSON (see https://www.boost.org/doc/libs/release/libs/json/doc/html/json/conversion/avoiding_physical_dependency.html).

[denzor200]

such feature can be a part ofBoost.PFR

Sounds really strange :) Boost.Json already have Boost.Desribe intergation, why? Doesn't it was better to make such feature a part of Describe? And then go futher and make xml, yaml, sql and anything else a part of PFR/Describe? Of course not, since they both are reflection libraries and they not obliged to be swiss knife for every reflection usecase.

BTW Boost.PFR is a great candidate to be used as fallback for type for which conversion is not found. And shoud we need it as fallback, it's possible to implement only on the Boost.JSON side.

[grisumbras]

By the same logic, Boost.JSON can't implement conversion logic for every reflection library and composite type in existence. How about this: if someone makes a JSON conversion implementation for PFR, I will integrate it as an example.

[schaumb]

If anyone is interested in a JSON lib that has default field reflection, check glaze. They use the same technique as boost PFR.

I think boost::json needs to support reflection without specifying anything information about structs.