Perhaps what you want is akin to the ability to pick out one name from a module, like so:
 
========file A.d:===========
module A;
class B {}
 
...
========file C.d:===========
module C;
 
import A.B;  // just bring in class B from module A
 
 
 
Except you want to be able to do away with module A entirely.
 
What if such a file were missing a module declaration, and the only name present in it matches the file name?
 
========file B.d:===========
class B {}
 
...
========file C.d:===========
module C;
 
import B;  // just bring in class B from B.d
 
Hmm.  It seems viable but I'm sure there would be other issues to work out.  What if class B needs some "global" support declarations?
 
A workaround for now might be public imports.
 
 
========file A.d:===========
module A;
class B {}
 
...
========file Stuff.d:===========
public import A.B;
 
...
========file C.d:===========
module C;
 
import Stuff.B;  // just bring in class B from A.d, via public import in Stuff.d
 
 
I seem to recall D used to have this behavior by default, and private imports were added to compensate.  So this might still work, I haven't checked.  You could pull in everything you need into one big library interface module, even though it actually lives in its own module in its own file.  But it requires such a library interface module.  That's not such a stiff requirement though, as this kind of thing would be mostly for library work anyway.
 
Sean
 
"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhme5o$jlf$1@digitaldaemon.com...
like templates (which are almost modules within modules) I think there there
is too much depth in the D names,
I think D needs a way to create a file that only contains one item, be that
a template, class, struct or other. so import a.b.c; looks for a/b/c.d  as
it does now; only the item imported may be a.b.c
rather than a.b.c.t.c or a.b.c.c etc;