Serialization is the canonical example. Being able to turn

    struct MyStruct {
      int val = 42;
      string name = "my name";
    };
    

into

    {
      "val": 42, // if JSON had integers, and comments of course
      "name": "my name",
    }

is incredibly powerfuly. If reflection supported attributes (i can't believe it shipped without, honestly), then you could also mark members as [[ignore]] and skip them.

You can achieve that since C++20 (or C++17 if you don't care about the member names). E.g. https://www.linkedin.com/posts/vittorioromeo_cpp-gamedev-ref...

(The link above shows ImGui generation, but the same exact logic can be applied for serialiation to JSON/YAML/whatever.)

Sure, but

> The magic sauce? Boost.PFR! An incredibly clever library that enables reflections on aggregates, even in C++17.

That's not vanilla C++!

...so what? It's just a header you have to #include.

By that logic why would anything have to be standardised?

The question is whether something belong in the language or in a library (possibly the standard library).

A guiding principle of C++ is that if something can be implemented cleanly and efficiently in a library, the language should not be extended to support the use case.

Now boost.pfr is exceedingly clever, but relying on speculative pack expansions or using stateful metaprogramming hacks is not something I would call clean and efficient, so proper reflection is warranted.

I do worry about the compile time impact though.

By your logic we shouldn't ever use external libraries.

PFR has given us reflection since C++14.

I also don't think the Standard Library is particularly well-defined nor well-implemented, as demonstrated by the atrocious compilation times.

The standard library shows the roots of the mid-1990s and there are a lot of things we would definitely do different today. However, it is still extremely well defined compared to most everything else. C++ is one of the few languages where the library actually guarantees how an algorithm works, which is both good and bad. The bad part is some things that made perfect sense in 1995 simply don't make sense in our modern CPUs where cache is important.

the only thing that should be standardized are things that cannot be done through libraries in an efficient way. Boost.PFR is great, I built a lot of things on it, but eventually you hit the limits of what a pure library approach can do -> language feature.

It is powerful, but I'm not sure it is a good idea. Other languages have it, and there is lots of experience in all the ways things go wrong in the real world. I'm inclined to say you should hand write this code because eventually you will discover something weird anyway.

Can you give an example of a language ecosystem that went with reflection-based JSON serialization/deserialization and then went on to regret it? I can't think of any, and don't agree with your conclusion. It works great, and manually writing serialization and matching deserialization code is terrible, annoying, error-prone work.

I disagree. Rust's defacto default is serde, golang comes with batteries included, dotnet/java have had it for _years_, and all the dynamic languages do it.

I think this is a very bad take -- once you write it by hand you have to manually keep it in sync with the actual struct and ensure you made no mistakes. Reflection guarantees 1-1 future-proof mapping with the actual C++ struct, avoids boilerplate, and ensures that the serialization logic is correct.

The protocol is important though, not the internal structure. When you only have exactly one version of a program talking to the same version of itself you don't care. However when you are mixing versions or worse programming language (and thus can't mix structs which are implementation details of your language) the protocol is what matters.

That is if you are worried about doing this by hand reflection is not the answer, something like protobuf where your data structures are generated is the answer.

I completely understand your point. Then again you might be able to use reflection to verify that your manually rolled implementation actually serializes all fields.

It comes up pretty frequently in java. Serialization/Deserialization, adding capabilities based on type, Adding new capabilities to a type, general tuning (for example, adding a timing or logging call onto methods).

Almost all the Java web frameworks are giant balls of reflection. Name a function the right way or add the right magic annotation and the framework will autowire it correctly.

It's a pretty powerful tool. (IDK if C++'s reflection is as capable, but this is what was enabled by java's reflection).

Java reflection is another beast altogether as it is runtime reflection. C++26 reflection is purely compile-time, which not only means it adds zero runtime cost, but also prevents those kind-of-insane use cases you see in Java and C#.

I think C++ devs have to eventually update their knowledge how Java and .NET work when talking about reflection.

Yes, originally they only supported runtime reflection.

Nowadays they have compile time tooling as well, via plugins, annotation processors, and code generators.

Which is exactly how you can have a Spring like frameworks that do all the AOP magic at compile time, for native code with GraalVM or OpenJ9, like Quarkus or Micronaut.

> Almost all the Java web frameworks are giant balls of reflection. Name a function the right way or add the right magic annotation and the framework will autowire it correctly.

I find this to be very powerful, and also very unintuitive/undiscoverable at the same time.

Initially, but it very quickly becomes discoverable once you are familiar with how things are working.

Most frameworks in Java are very similar. The ones that aren't are effectively doing what "expressjs" does in terms of setup, which is still pretty discoverable.

Most java frameworks rely on annotations rather than naming schemes which makes everything a lot easier to grok.

Reflection is simply a syntax vinegar for duck typing.

Anybody the derive traits rust has are a good demo.

I mean a readable implementation of tuple with minimal overhead is a great case for me (went from around 1.6k lines to approximately 250 lines). I wrote an implementation including the normally difficult to implement tuple_cat based on c++26 within a few hours.

My favorite thing is that I will get to remove and replace most of the cryptic template recursion stuff I have with "template for" and maybe a bit of reflection. Debugging the unrolled stuff will be a joy in comparison.