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/uladyipxlerudtmsl...@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?