is `allMembers` useless for modules?

[FeepingCreature]

On Monday, 14 January 2019 at 14:06:02 UTC, Atila Neves wrote:
>> It lists imported packages and modules, even though there's no 
>> way to detect if a symbol is a module
>
> Sure there is: `enum isModule(string moduleName) = 
> is(typeof(mixin(`{ import `, moduleName, `; }`)))`
>

Right, to restate, there's no non-brute-force way. This should 
really be a trait; if the compiler offers you a symbol, it should 
also give you a clean way to determine the nature of that symbol.

>> and there's no way to go from the package to the modules it 
>> contains.
>
> This is true. There's currently no other way than listing 
> modules to reflect on in a source file somewhere, but this can 
> be automated.
>

This cannot be automated if you don't know the include path of 
the source file. You basically have to manually reproduce D's 
include search logic.

>> It does not list named imports at all, for basically no reason 
>> I can tell.
>
> I'm not sure what you mean by this.
>

For instance, if you `import std.string : split`, then split will 
not be visible in the allMembers list whether or not you imported 
it public. Though on reflection it's probably more that 
allMembers specifically excludes imported symbols.

> Ah. I'd use dmd as a library for this. I even started writing 
> the code to do exactly this.

It's silly and disturbing to me to have simple reflection 
information available in DMD running as a library, its secondary 
purpose, that is not available when running DMD as a compiler, 
its primary purpose, for basically no good reason.