[cfe-dev] Reflection TS

[David Rector via cfe-dev]

> 
> 
>>>> First, though, perhaps consider your goals, as I’m not 100% sure the
>>>> Reflection TS is the last word on the subject of reflection — though
>>>> others certainly disagree with me.
>>> 
>>> Just wanted to chime in on this with my 2c.
>>> 
>>> The Reflection TS is certainly not the last word on the subject of
>> reflection -- an improved version of reflection facilities are being worked
>> on for a future C++ standard (such as C+23 or C++26).
>>> 
>>> However, the purpose of the Reflection TS is to gather implementation
>> and use experience to guide such improvements prior to final
>> standardization.
>>> 
>>> I think it would be very valuable to implement the Reflection TS so that
>> we can gather such use experience.
>> 
> 
> For what its worth, I plan on continuing to work on my fork to get as close
> to a complete implementation of the current TS.  If nothing else, it'll
> help me understand some of the challenges going forward so I can contribute
> more constructively to these conversations.
> 

A good plan.  I was in the same boat as you about a year and a half ago, learned clang just to implement reflection I needed for another project, and that knowledge has been very useful.  If nothing else it will expose you to clang’s AST, so that by pursuing your project, one way or another at the end you will gain the ability to work with “reflected” info in your other projects — either via your reflection implementation, or via external clang tools etc. for more complete pseudo-reflection capabilities.

> 
>> I am even considering forking clang semi-permanently just to be able to
>> clean up the AST in this way — if there are others interested in developing
>> a "stable AST" fork — the main job would be standardizing names, improving
>> the documentation, factoring out helper bases, etc. — please let me know.
> 
> 
> I would definitely be interested in helping out with such a project, though
> I will say I'm a bit concerned that forking for so long would make it
> extremely difficult to merge back at some point.  Are there any ongoing
> discussions regarding refactoring the AST in this way?  Or would this be a
> new effort?
> 
> I'm curious how such a big change would be viewed by the rest of the
> community as this would affect a lot of developers.
> 
> Best,
> Nick


It seems, given the lack of response whenever it is broached, that there is not much support for cleaning up the AST and making it stable, or even distinguishing between the stable/unstable parts with annotations.  Which is sad because it would seem certain benefit many different projects, while making the AST more novice-friendly.   I think this is true even putting aside the benefit of permitting direct AST reflection support.  

Perhaps the leadership might respond with the reasoning behind the “unstable AST” policy, or link to where it has been explained elsewhere; I’m sure there are at least a few others as curious/unsatisified about this as I am.  If there is some greater wisdom I am missing, I would love to learn it.

I suggested originally that you be sure to keep your goals in mind as you proceed.  The goal of learning the clang AST is a good, achievable one.  The goal of implementing the Reflection TS in terms of your own custom Expr nodes and language keywords is achievable as well, and may well have some utility for you and many others for a time.  

However, also consider this: the proposals for intrinsic reflection/metaprogramming language keywords which I’ve seen considered will not, I believe, survive the half-decade or so until they are to be standardized, because they seem to me a toxic combination of a) intricate, requiring the user to learn an entire new language and developers to maintain it, and b) incomplete — not giving the user enough keywords in that new language to do everything they will eventually want to do.  

The result, if pursued, will be that more and more keywords will be added to this side-language over time, and as developers struggle to implement them in terms of new compiler intrinsics, they will notice the collection of intrinsics more and more resemble a distorted and incomplete image of the AST itself.  You thus might call this “funhouse-mirror” reflection, only unlike a funhouse mirror, this distorted and incomplete image needs to be manually produced and maintained by developers.

As these burdens are recognized, I believe developers will come around to “straight-mirror reflection”:  clean up the AST, stabilize it, and reflect it in its original object-oriented structure to the user via a tool run automatically during the clang build.  Common std library type traits etc. should then be defined in terms of those; no custom intrinsics need to be gradually added and maintained.  That gives the user all the reflection functionality they could possibly desire when they don’t care about portability with other compilers, while not impeding the standardization effort for those that do.  

Enough of my proselytizing.  Bottom line for you: approach your project with the understanding all this is still in the experimental stage; your implementation may not last through the ages, and may not even be used or garner any appreciation at all, no matter how good it is.  So long as plan to learn from it, and/or get your implementation to do what you need it to do for your other projects, it’s certainly worth it, believe me.  You seem to have a good plan and healthy perspective already so I encourage you to go for it.  Be sure to ask questions to this list rather than banging your head against a wall, people here have some great info and advice that is not always documented in the source.  

Good luck,

Dave