Find symbol in unknown module at compile time?

[bitwise via Digitalmars-d]

On Sunday, 7 December 2014 at 06:25:48 UTC, ketmar via 
Digitalmars-d wrote:
> On Sun, 07 Dec 2014 05:42:31 +0000
> bitwise via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
> what you actually want is some cross-module compile-time data 
> storage.
> this is impossible to implement. at least to make it reliable.
>
> with separate compilation, for example, you can't get list of 
> "all
> modules", 'cause we can link other unimported modules to the 
> final
> executable. this is somethimes useful with "extern", for 
> example.
>
> and there is no such thing as "main module" too, so there is no 
> "root"
> for symbols.
>
> besides, some templates can be not instantiated at the time you 
> doing
> compile-time reflection, for example. that is why my console-ng
> requires that "register all" mixin must be the last line in the 
> module.
>
> with some efforts and hackery you can walk all imported 
> modules, but
> this can fail at unexpected places.
>
> tl;dr: things aren't that easy when it comes to compile-time
> reflection. either live that to runtime or write compile-time 
> wrappers
> and restrict compile-time reflection usage to well-defined 
> places and
> patterns.

I think I understand what you mean. I've been surprised with the
way D is able to handle circular references, but I guess there
still has to be some order of initialization at the end of the
day.

Thinking about my current design, I believe there are places
where circular references could cause problems, but that I have
yet to find them because I haven't properly tested against a
large/complicated codebase.

I think the best plan for me would be to store all reflection
information in the reflection module itself as local static
variables of templates, i.e. Meyers singleton style. This would
disallow me from reflecting private members, but would greatly
simplify my design. Also, the mixin could then be used
exclusively for registering runtime reflection, and be placed
anywhere.

I would like to be able to reflect private members though... Is
there any way to give a module private access to an unrelated
module?

I'm thinking of something like placing a pragma at the top of a
module or adding a qualifier to a module declaration.

#pragma privileged
or
module reflection privileged;

I understand that packages are meant to solve this problem for 
regular code, but given the fact that D has such a comprehensive 
reflection system, it would be nice to have this special case.