Import concerns revisited

[Don Clugston]

John Reimer wrote:
> 
> "Walter Bright" <newshound at digitalmars.com> wrote in message 
> news:e8utvp$53$1 at digitaldaemon.com...
>> John Reimer wrote:
>>> If you can find something
>>> equivalent to from/as (which you most certainly haven't), without 
>>> adopting new
>>> syntax, maybe we'll bite... but so far, I think using 'with' (or 
>>> from) and 'as'
>>> is an excellent contender.
>>
>> I'll repeat myself here, too <g>. The 'static import' combined with 
>> 'alias' has
>>
>> *exactly the same semantics*
>>
>> as 'with' 'as'. The only difference between the proposals is if there 
>> are two statements or one. There is no difference in power or effect. 
>> There is nothing that one can do that the other cannot.
>>
> 
> 
> The semantics are not exactly the same.  Read Sean and Kris's 
> explanations again, please.  'static import' adds nothing to the what 
> this whole namespace business.  It just sharpens the compiler a bit to 
> enforce FQN for the programmer's sake.  But that is absolutely 
> unnecessary because a D programmer that wants to do that now can just 
> make sure he uses FQNs!  So what's the point of 'static import'?

I have to disagree with this. Currently, suppose you have a module that 
uses the toString() functions from std.string (and uses them hundreds of 
times). Then, you decide you need to use std.date in one place to get 
the current time. Suddenly, your module won't compile, because 
std.date.toString() conflicts with all the other toString()s that you're 
using. Even though you're not even using std.date.toString !

With the static import proposal, you could just have

import std.string;
static import std.date;

and then use FQNs for the single usage of date.

This is not a contrived example, I encountered it in my second D program 
(and I immediately thought that there were serious problems with the D 
module system. You're telling me I have to alias std.string.toString 
just because I want to use std.date.getUTCtime() ???). 'static import' 
would make it possible to avoid the use of FQNs in most cases; it would 
enable you to distinguish 'I'm going to use a function from this module' 
(static import) from 'I'm heavily depending on this module' (normal import).

Which is not to say that I'm favouring 'static import' in this 
discussion, I'm simply saying that all of the proposals, including 
static import, are an *enormous* improvement over what we have now.