So I do think you’re right that reflection can (and will) be abused by beginners if present as a language feature.
With that said, I don’t know much about the internals of the C++ compiler, but having built a simple reflection system for C++, I think the important thing is just being able to serialize and deserialize POD structs to and from some representation (e.g. json). For more advanced data, such as images or specific binary (file) formats, it’s easier to write custom writing / reading, encoding / decoding logic.
Why not just use a visitor? (Genuine question, not c++ snark).
Fundamentally, if I have struct { int x = 3; std::string y = "bla"; }
I want the json to look like { x: 3, y: "bla" } without writing any code specific to the struct, and have it work bidirectionally. This is currently not possible because of a lot of reasons, but most trivially because the names "x" and "y" do not even exist anymore in your compiled code.
> Boost.PFR library works with types that satisfy the requirements of SimpleAggregate: aggregate types without base classes, const fields, references, or C arrays:
And in general seems to be dependent on C++20 for getting field names.
Do you know how this works? Initializer lists seem somehow involved.
C++26 reflection is compile-time reflection, not runtime reflectiom, it doesn't require any extra information in the binary. It just uses information that the compiler already has at compilation time.
For example, C# and Java have their intermediate language that has a bunch of meta information attached to it already or the info can be added easily if need be. Is C++ not more raw in its compilation process from code to object files? I mean sure, I guess meta-data could be added to the object files themselves for runtime inspection, but if it were really that simple, why wouldn't they have just added it if reflection is indeed that much of a sore spot for the language's purpose?
Now, I'd like to add, my understanding of compiler internals is quite limited, so if I'm way off base here, please correct me.
Additionally, while I too find reflection useful, I've seen a lot of cases where it ends up being a bandaid for poor design and gives people an all too enticing shovel to dig themselves deeper into a hole of technical date. When used correctly, reflection can be quite elegant, but I think those cases are seldom advantageous in comparison to a different likely better design approach.