[cfe-dev] Reflection/metaparsing implem

[David Rector via cfe-dev]

I argue the standards should be based on the clang AST.  Clean it up first of course — and yes that alone would be extraordinarily difficult.  But it’s also very difficult to build a gigantic parallel naming system for reflection properties.  And then to maintain it long term…

Best to look hard at what lies ahead, and bite the bullet now.  Clean up the AST, define the standard via it.  (And c’mon we all know those AST nodes have a lot of flab to go with all their muscle; clang would benefit too after we all finish grumbling about the changes.)  Other compilers can do a parallel naming system or adjust their own ASTs to match clang’s naming system — doesn’t need to add any work for them.

Dave

> On Nov 11, 2019, at 12:49 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Mon, Nov 11, 2019 at 8:43 AM David Rector via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> Please enjoy this clang 7.0.0 fork:
> 
> https://github.com/drec357/clang-meta <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.
>  
> but I sense that will be an uphill battle.  Please let me know if you would support this way of doing reflection/metaprogramming, or have suggestions on how to proceed.
> 
> David Rector
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <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/c6b631aa/attachment.html>