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

[Don Clugston]

Tyro wrote:
> 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

But how does it know that std.string is a module? It could be a sequence 
of classes, for example.

class std {
  class string {
    void writefln(str[]...);
  }
}

If you're not using anything from std, I think that would be perfectly 
legal. Unlikely in the case of std.string, but in general...

Declaring imports is IMHO a lot like declaring variables. Not strictly 
necessary, but it saves you from lots of hard-to-track down bugs.