Compile-time list of imported modules

[Vladimir Marchevsky]

Practical example: some framework allows it's user to define 
types of some messages. It can be done by manual calls like 
`something.registerMessage!T1()`, 
`something.registerMessage!T2()`. Other way is to leave it to 
framework: just annotate `T1`, `T2` with `@Command` UDA and call 
some core framework mixin once to generate all the boilerplate.

And here come troubles. `getSymbolsByUDA` is not recursive and 
works for single module only. At the same time it seems there is 
no way to list all imported modules to get symbols from them. So 
we are back to boilerplate - just listing manually all modules 
this time instead of all types.

I've seen this thread during my search: 
https://forum.dlang.org/thread/uladyipxlerudtmsljky@forum.dlang.org

> __traits(allMembers, package) will list names of imported 
> packages but not which modules.

In my tests it resulted in something like `"object", "framework"` 
for `__traits(allMembers, framework)` (I'm omitting all actual 
types in it as we talk about modules only). Why is it done this 
way? How is it useful?

> How to list unknown sub-modules? (and not walking the source 
> tree dir). Is there a compile time solution to this problem?
> No. Sorry. Generally compile time code cannot interact with the 
> system.

Well, we have string imports. Being able to walk the source tree 
doesn't look worse than being able to read files, no? But anyway, 
that was said with **unknown** modules. Imported modules are 
already known for module that imports them, right? So logically 
you don't need to interact with system, it's already just a part 
of your app.

Is it still impossible? Why?