A C++20 library for fast serialization, deserialization and validation using reflection. Supports JSON, BSON, CBOR, flexbuffers, msgpack, TOML, XML, YAML / msgpack.org[C++20]
This issue is a long-standing TODO list towards enabling compile-time serialization and deserialization (the latter is of which particular importance).
Why do we need compile-time (de)serialization?
The idea is not new. json2cpp by Jason Turner (the guy from C++ Weekly, guess where I got the title for this issue from) already kind of provides this functionality.
The reasoning is simple. One might want to make compile-time decisions based on some kind of JSON configuration instead of having to set a bunch of #defines or whatnot. With C23 having added #embed and C++ probably doing so at some point, this would be even cooler as the JSON/whatever serial format wouldn't even have to live as crust in a header file, it could just be pulled from the filesystem from a normal .json file. The possibilities are endless.
Lastly, I propose the following counterpoint: why not?. For years people have been making cool constexpr capable projects (CTRE by Hanickadot being an excellent example). The work you can do at compile-time is the work that's guaranteed not to incur in undefined behavior (constexpr code is not allowed to have undefined behavior). If only for the assurance of safety of the library on its own, since we could have compile-time tests rather than runtime tests, this is excellent.
It is also generally quicker if you manage to precompute import parts of programs. Do we really need to read that JSON file that's supposed never to be modified by the user at the start of our program anyway? Doesn't it kind of suck that they can modify it too? I wish we could just embed this into our program in an easy way...
We might not know all of the uses this could have a priori, but that doesn't mean we shouldn't go ahead with this (especially given there is already the excellent use case described above). This is a no-brainer.
TODO
What follows is a list of tasks to be done in this regard. New points will be appended to it as time goes on and we figure out more stuff that needs to be done before the final objective is done. PRs or commits that check particular boxes should be added here too for tracking's sake.
[ ] constexpr-friendly rfl::Result and rfl::Error
[ ] Compile-time serialization and deserialization
This issue is a long-standing TODO list towards enabling compile-time serialization and deserialization (the latter is of which particular importance).
Why do we need compile-time (de)serialization?
The idea is not new. json2cpp by Jason Turner (the guy from C++ Weekly, guess where I got the title for this issue from) already kind of provides this functionality.
The reasoning is simple. One might want to make compile-time decisions based on some kind of JSON configuration instead of having to set a bunch of
#defines or whatnot. With C23 having added#embedand C++ probably doing so at some point, this would be even cooler as the JSON/whatever serial format wouldn't even have to live as crust in a header file, it could just be pulled from the filesystem from a normal.jsonfile. The possibilities are endless.Lastly, I propose the following counterpoint: why not?. For years people have been making cool
constexprcapable projects (CTRE by Hanickadot being an excellent example). The work you can do at compile-time is the work that's guaranteed not to incur in undefined behavior (constexprcode is not allowed to have undefined behavior). If only for the assurance of safety of the library on its own, since we could have compile-time tests rather than runtime tests, this is excellent.It is also generally quicker if you manage to precompute import parts of programs. Do we really need to read that JSON file that's supposed never to be modified by the user at the start of our program anyway? Doesn't it kind of suck that they can modify it too? I wish we could just embed this into our program in an easy way...
We might not know all of the uses this could have a priori, but that doesn't mean we shouldn't go ahead with this (especially given there is already the excellent use case described above). This is a no-brainer.
TODO
What follows is a list of tasks to be done in this regard. New points will be appended to it as time goes on and we figure out more stuff that needs to be done before the final objective is done. PRs or commits that check particular boxes should be added here too for tracking's sake.
constexpr-friendlyrfl::Resultandrfl::Error