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

[Tyro]

John Reimer wrote:
> In article <e9kp1b$hcm$1 at digitaldaemon.com>, Boris Wang says...
>>
>>> Ah... ok. Good to know. I guess we have a very flexible system in place, 
>>> capable
>>> of accomodating several styles.  And Walter gets to have his "static 
>>> import" as
>>> well. :)
>>>
>>> -JJR
>>>
>>>
>>>
>> No, I don't think so.
>>
>> Something need refining.
>>
>> 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
>>    ...
>> }
>>
>>
> 
> Yes, I understand that there's a bit of a redundancy in the current
> implementation, but I'm not sure the above solution is good one or really
> necessary.  An import statement seems to give the compiler a quick lookup hint,
> and meanwhile acts as a documentation tool indicating which module is going to
> be used in a program.
> 
> The above is certainly a possibility for what might be termed "implied
> importing".  But I'm not quite comfortable with it.  At this point, I don't have
> any comments to the negative other than that, for the time being, I think we
> have pushed the import issue far enough. :)
> 
> -JJR
> 
> 

List time I checked this was not implemented in D. For that matter it 
has never been implemented in D. If you want to reference a function in 
a module you have to import the module or, in the case of the most 
recent implementation, selectively import from the module in order to 
access the desired functionality.

As I understand it, the question Boris is asking is why do this:

| import std.string;
| void main()
| {
|   writefln("Now I can use it");
| }

When you can do this:

| //import nothing
| void main()
| {
|   std.string.writefln("Here I simply use it");
| }

I think he's got a point.

The compiler already knows how to find std.string and it can decipher 
whether or not a requested functionality is implemented in the module. 
Therefore it should be smart enough to *implicitly* import that 
function/module using FQNs alone.

Andrew C. Edwards