what's the difference between 'static import =' and 'import ='?

[Bruno Medeiros]

pragma wrote:
> In article <e9kp1b$hcm$1 at digitaldaemon.com>, Boris Wang says...
>> Why not discard the sentence 'static import' ? When you need FQN to access a 
>> package, just do it.
>>
>> For example
>>
>> int main(void)
>> {
>>    std.stdio.writefln("Just do it"); // not need any importing
>>    ...
>> }
>>
> 
> This won't work because its not guaranteed to be non-ambiguous.  Thanks to how D
> layous out namespaces, the FQN "std.stdio.writefln" isn't necessarily the method
> "writefln" in module "std.stdio".  For example, the following module:
> 
> // std.d
> module std;
> struct stdio{
> class writefln{
> static opCall(){ /*...*/ }
> }
> }
> 
> ... could be placed on DMD's include path and match the 'implicit' import you
> describe above.
> 
> This more or less requires a series of compiler behaviors, none of which are a
> really good idea IMO.  Should the compiler accept all possible variants of an
> FQN for matching, then you get this in the worst case for *every* FQN:
> 
> - Parse *all* files on the current include path for matching FQN's
> - Report an ambiguious match as either an error or warning
> - In the case of a warning, pick one of the matching modules for inclusion and
> continue.
> 
> - EricAnderton at yahoo

Forget the option of reporting an warning. Such situation should be an 
error, just as this is:
   import pack;
   import pack.foo; // pack conflicts.

And the the compiler search behavior would be complicated. For an access 
like:
   x.y.z.foo();

Then for each path in the include path, search the root dir for a x 
module or package. If there is more than one match (or no matches) 
report an error. Otherwise, use the found match, and recurse the search.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D