I'm not sure C++26 reflection is sufficiently well-baked to actually allow it to be used for serialization boilerplate in codebases. What matters is not what the standard says, but what the compilers implement, and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.
reply> and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.
replyOut of curiosity, would you be able to elaborate on (or link to?) what makes reflection so problematic?
Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.
replyReflection is likely useful for a lot of things, but I agree serialization need a better framework.
replyYes, C++26 reflection is nice, but also extremely complex to understand and use well. The rest of C++26 is the usual series of too-little-too-late additions. Meanwhile I’m still waiting for pattern matching to become a thing (a proposal has been discussed for ages)
replyI can't think of a time where using reflection for serialisation hasn't come back to bite me.
reply