<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 11, 2019 at 10:29 AM Arthur O'Dwyer via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Nov 11, 2019 at 7:50 AM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Nov 11, 2019 at 8:43 AM David Rector via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Please enjoy this clang 7.0.0 fork:</div><div><br></div><a href="https://github.com/drec357/clang-meta" target="_blank">https://github.com/drec357/clang-meta</a><div><br></div><div>This reflection implementation reflects just about the entire clang AST, and lets you use clang syntax/names in *regular, non-clang* C++ code:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>namespace ns { class MyClass { float f; }; }</div><div>constexpr {</div><div><span style="white-space:pre-wrap"> </span>ce_assert(reflexpr(ns)->isInline());</div><div><span style="white-space:pre-wrap"> </span>ce_assert(!reflexpr(ns)->isAnonymousNamespace())</div><div><span style="white-space:pre-wrap"> </span>FOR ( (Decl *D) : reflexpr(ns::MyClass)->decls()) {</div><div><span style="white-space:pre-wrap"> </span>if (auto_ FD = dyn_cast<FieldDecl>(D))</div><div><span style="white-space:pre-wrap"> </span>FD->dump();</div><div><span style="white-space:pre-wrap"> </span>}</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>//As for meta-parsing:</div><div><span style="white-space:pre-wrap"> </span>__queue_metaparse("static const int i = ");</div><div><span style="white-space:pre-wrap"> </span>constexpr int ival = __metaparse_expr(__concatenate("3", 2+2), int);</div><div><span style="white-space:pre-wrap"> </span>__queue_metaparse(jval);</div><div><span style="white-space:pre-wrap"> </span>__queue_metaparse(";")</div><div><br></div><div>} // queued metatparses performed here…</div><div><br></div><div>static_assert(i = 34);</div></blockquote><div><br></div><div>Plus you can define clang-style diagnostics and FixItHints, using reflected SourceLocations, in your regular, non-clang code.</div><div><br></div><div>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, </div></div></blockquote><div><br>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.<br></div></div></div></blockquote><div><br></div><div>Very true. However, this looks like a very promising <i><b>Clang-specific</b></i> feature that might make life easier for <i><b>Clang users</b></i> who want to use reflection features. </div></div></div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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</div><div>- implementation experience and</div><div>- motivation</div><div>to consolidate and standardize the implementations into a <b><i>standard reflection facility</i></b>.</div><div><br></div><div>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."</div><div><br></div><div>my $.02,</div><div>–Arthur</div><div><br></div><div><br></div><div><br></div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>