Proposal for an extension to the import syntax

[Chris Nicholson-Sauls]

Trevor Parscal wrote:
> Why not just use
> 
> import package.*;
> 
> it makes sense in regexp statements, it works for java, why not use it here?
> What's the problem?

Problems:

1 - Inexpressiveness.  (Is that a word?)  Assuming a random reader, peer reviewer, 
maintenance coder, or what have you is fully familiar with the library/package being 
imported, then there is no problem in this sense.  Assuming they are less than fully 
familiar -- probably far more often true than not -- now they have to go and find a list 
of all members of that package in order to have some idea of what's being added to the 
namespace.  With the current situation, you can see the names of modules being imported, 
and so have (more likely at least) some idea of what's being put into the namespace.

2 - Depth ambiguity.  Given a package structure:
   /mylib/alpha.d
   /mylib/beta.d
   /mylib/utils/mercurius.d
   /mylib/utils/venus.d

And given the import statement:
   import mylib .* ;

What has been imported?  Or in other words, is the 'utils' subpackage included in this 
sweeping import?  Or must sub-packages be imported independantly?  (Yes, yes, of course an 
implementation would state this in stone somewhere... but imagine the debates needed to 
decide the course of that implementation.)

3 - Pollution.  If you need three modules out of a package of thirty, do you really want 
to put up with all the potential symbol collisions from a bunch of cruft you aren't even 
using??  Do you want to have to but that dangling dot (module scope specifier) in front of 
your local symbols just to disambiguate them from functions you never call, or classes you 
never instantiate, etc etc etc?  I know I sure as heck don't.

4 - Aesthetics.  Call me weird, and note I have done some work in Java, but I just plain 
don't like the look of the .* syntax for some reason.  :)

-- Chris Nicholson-Sauls