There are some ideas on how to solve this in the "Unresolved issues" section but it is rather complicated:
- If we allow everything to be reflected the compile-times would be horrible, even worse if a run-time reflection facility was based on this meta-data so would be the resulting executable size.
- If we allow some sort of "white-listing" (i.e. specify what you want) or "black-listing" (specify what you don't want) it would be inconvenient for some use-cases.
I'm a fan of the "white-list" approach, but I would like to hear your opinions on this issue.
Whitelisting seems appropriate. To make it more convenient, it would be nice to be able to white-list at different granularities - for example, an entire namespace (meaning all its contents), or just particular elements of a namespace.
I also like the idea of separating the whitelisting from the definition of the namespace/class. For example, I may *want* to traverse all the elements of namespace std, so I should be able to whitelist it in my code only.
Yes it may be a legitimate use case to traverse everything and this is where it would be annoying to have to re-specify everything so the white list should allow to use some kind of wildcard even if only for the "get everything" case. The paper describes a tagging mechanism and IMHO some kind of combination of white-listing and compile-time filtering based on the user-specified predicates examining the tags and various properties of the meta-data would be "best". regards, Matus