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

[John Colvin]

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

I'm not 100% sure I follow what you need, but maybe one of these 
two will help:

`interface FunctionBase` and `class Function(string name) : 
FunctionBase`.

or

Use a templated constructor `this(string name)()`, so the fields 
are filled during ctfe using "template-time" information. This 
way the type stays the same.