[jcranmer]

The main canonical use case for static reflection is serialization, where serialize<T>() can easily have a default case of calling serialize() on each of the fields. In the more general case, you basically want to have some library method that does something based on the structure of a struct or class, without having to define some sort of explicit, intrusive interface that said struct or class implementation has to provide.

Does static reflection simplify such cases? ... Outlook unclear. It's definitely gnarlier to actually write the serialize() method, and in many cases, it does feel like a better option is to write a specific domain-specific language to specify what you want to specify, with a tool to operate on it as appropriate (think something like protobufs for serialization).

[petters]

Serialisation often needs additional information not present in the struct definition: for enabling backwards-compatibility and default values.

Same for command line parameters. We want documentation strings, maybe dashes in the name etc.

But that can surely be solved with a little more advanced struct

[einpoklum]

I have one word for you: attributes (which the compiler, and the reflector, know about).

[petters]

Yes you’re right. That has worked well enough in other languages