Workaround for https://issues.dlang.org/show_bug.cgi?id=18422?

[Seb]

On Sunday, 11 February 2018 at 15:34:07 UTC, Andrei Alexandrescu 
wrote:
> I'm trying to sketch a simple compile-time reflection system, 
> and https://issues.dlang.org/show_bug.cgi?id=18422 is a blocker 
> of the entire approach. My intent is to have a struct Module, 
> which can be initialized with a module name; then:
>
> struct Module
> {
>     private string name;
>     Data[] data(); // all data declarations
>     Function[] functions();
>     Struct[] structs();
>     Class[] classes();
>     Union[] unions();
>     Enum[] enums();
> }
>
> Then each of those types carries the appropriate information. 
> Notably, there are no templates involved, although all code is 
> evaluated during compilation. Non-data information (types, 
> qualifiers etc) is carried as strings. This allows for simple 
> arrays to convey heterogeneous information such as "all 
> functions in this module", even though their signatures are 
> different.
>
> This makes for a simple and easy to use system for 
> introspecting things during compilation. Clearly in order to do 
> that some of these compile-time strings must be mixed in, which 
> is why https://issues.dlang.org/show_bug.cgi?id=18422 is so 
> problematic.
>
> Until we discuss a fix, are there any workarounds?
>
>
> Thanks,
>
> Andrei

Here's a workaround:

---
auto moduleSys(string name)()
{
     static struct Module
     {
         auto allMembers()
         {
             import std.range : only;
             assert(__ctfe);
             mixin("static import " ~ name ~ ";");
             return only(mixin("__traits(allMembers, " ~ name ~ 
")"));
         }
     }
     return Module();
}

unittest
{
     enum x = moduleSys!"std.typecons".allMembers;
     pragma(msg, x);
}
---


https://run.dlang.io/is/t8KPfq