[cfe-dev] Reflection TS (Nick Meyer via cfe-dev)

[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.
> 

Yes, but the reflection TS offers only a subset of possible reflection facilities (e.g. no statement/expression reflection), and so the final product after examining use cases would be some subset of that subset.  And you’d have to convince implementers to implement this temporary, limited feature, and users to learn it and use it, to base your usage decisions on it.

I’ll rehash my already-implemented solution (https://github.com/drec357/clang-meta/, haven’t updated the git in awhile, but working on big fixes to be out in a month or two).  This has already been debated, but just for any who haven’t seen it:

1) Straight-mirror-reflect the entire public AST interface via a clang tool run on the compiler AST headers during building of the compiler. 

The result lets a person call 
    __clangrefl(somefunc)->isConstexpr() or
    __clangrefl(somefunc)->getBody()->…

and, if other compilers would get onboard,
    __msvcrefl(somefunc)->… 
    __gccrefl(somefunc)->…
etc.

Any public const methods/fields the compiler uses in its AST nodes, the user can access in his/her constexpr functions.  Current clang users could mostly copy and paste their clang tool code into constexpr metafunctions — you’d have an experienced user base right from the get go.

2) Standardize commonly used reflection type trait properties (the Reflection TS for now) into a std library that calls these builtins, the same way e.g. std::is_trivially_destructible is defined via a builtin.

You could implement the whole Reflection TS in an afternoon right now in terms of the builtins exposed by current implem — however because the clang AST API is not stable, they do not have interest in exposing the AST methods via such builtins, given that some might change over time, and so my fork is on its own.

So just like the case of the ASTMatchers thread I weighed in on earlier, the clang AST is the bottleneck, and because of its issues, the only available option is to implement a parallel architecture of reflection type traits.  I.e. we have to implement yet another parallel AST to wallpaper over the inner one.

If only all these efforts — on ASTMatchers, on reflection, on all other efforts to add new AST-like code to interface with a stable, more user-friendly version of the AST, could be redirected to making the AST itself stable and more user-friendly.  One could explicitly annotate just the stable parts or just the unstable/ugly parts to maintain some play; so that e.g. just the stable parts could be reflected or otherwise dependend on.

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.

Dave