[cfe-dev] Reflection/metaparsing implem

[David Blaikie via cfe-dev]

On Mon, Nov 11, 2019 at 10:29 AM Arthur O'Dwyer via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

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

I think that'd still be a pretty hard sell - Clang's APIs and AST are
volatile & intentionally so. People writing against the Clang APIs
themselves with things like clang-tidy are aware of that. If we sold this
as a feature to general C++ users, I don't think there would be a way to
sufficiently communicate how volatile this will be - and end up backing
ourselves into a corner & limiting the ability to change Clang.


> 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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191111/90589c0c/attachment.html>