[cfe-dev] Reflection/metaparsing implem

[Arthur O'Dwyer via cfe-dev]

On Mon, Nov 11, 2019 at 7:50 AM David Blaikie via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Mon, Nov 11, 2019 at 8:43 AM David Rector via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Please enjoy this clang 7.0.0 fork:
>>
>> https://github.com/drec357/clang-meta
>>
>> This reflection implementation reflects just about the entire clang AST,
>> and lets you use clang syntax/names in *regular, non-clang* C++ code:
>>
>> namespace ns { class MyClass { float f; }; }
>> constexpr {
>> ce_assert(reflexpr(ns)->isInline());
>> ce_assert(!reflexpr(ns)->isAnonymousNamespace())
>> FOR ( (Decl *D) : reflexpr(ns::MyClass)->decls()) {
>> if (auto_ FD = dyn_cast<FieldDecl>(D))
>> FD->dump();
>> }
>> //As for meta-parsing:
>> __queue_metaparse("static const int i = ");
>> constexpr int ival = __metaparse_expr(__concatenate("3", 2+2), int);
>> __queue_metaparse(jval);
>> __queue_metaparse(";")
>>
>> } // queued metatparses performed here…
>>
>> static_assert(i = 34);
>>
>>
>> Plus you can define clang-style diagnostics and FixItHints, using
>> reflected SourceLocations, in your regular, non-clang code.
>>
>> Please adapt to any uses you see fit!  I would love to see this way in
>> the C++ standards, much more general and low-maintenance than the proposals
>> I’ve seen,
>>
>
> One quick caveat: If it's general and lower maintenance by exposing
> Clang's AST directly, that is probably a significant deterrent to this
> being standardized - Clang's AST changes and it's not the same as other
> compilers ASTs, so generalizing this across compilers and across time might
> be quite difficult.
>

Very true. However, this looks like a very promising *Clang-specific*
feature that might make life easier for *Clang users* who want to use
reflection features. If people started using this feature, and then GCC and
MSVC got on board with their own GCC-specific and MSVC-specific reflection
facilities, then we might end up in a situation where we had both
- implementation experience and
- motivation
to consolidate and standardize the implementations into a *standard
reflection facility*.

The current WG21 standardization process puts the cart before the horse —
they have a Reflection subgroup attempting to design a standard reflection
facility prior to any vendor implementation experience and without any body
of existing practice (motivation) to guide their design.  It might be worth
seriously considering "practical" works like this one, at least far enough
to see what's wrong with them besides "lack of ISO involvement."

my $.02,
–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191111/68e689ab/attachment.html>