Import concerns revisited

[Lucas Goss]

Walter Bright wrote:
> But *are* they the usual case? As far as I can tell, Python is the only 
> significant language that allows aliasing of import names (though the 
> Python manual calls it "binding"). (We'll set aside the C++ #define 
> trick as not a reasonable method.) I haven't seen it used in Python 
> code, though I admit I haven't seen much Python code.
> 
> That's why I suggest just trying it for a while. Kris' original concerns 
> are met with the combination of 'static import' (I know, I know, should 
> think of some better keyword combination) and 'alias'. Syntax changes 
> should be done conservatively - if there's an existing way to do it, it 
> has to be used a lot to justify special syntax for it.
> 
> Kris brought up 'goto' - sure, we can do a 'while' loop with a goto, but 
> loops are so very, very common that special syntactic sugar for it has 
> proven to be a big win.
> 
> D already has a lot of syntax in it. We should be very careful about 
> adding more; not every convenience should have its own syntactic sugar.

I can see your concerns and after trying out some ideas I partly agree.

I just wish I knew who broke the dam because I don't like this water 
under the bridge. Having the FQN as default seems to be the best 
solution as any keyword before import seems like a kludge. And I think 
this syntax would be nice:

(1)
import std.math.*;
import std.stdio.writefln;
import std.stdio.writef;

While the list style is nice in that it's a little less typing, and the 
static is somewhat nice in that it doesn't break existing things:

(2)
static import math;
import std.stdio : writefln, writef;

The argument that a rename of the base library (in this case std.stdio) 
would be a pain to update I don't think holds. A rename is a simple find 
and replace, which most text editors do simply. The vertical layout of 
the first for me is easier (in my opinion) to read, and anything before 
import makes the statement more confusing (as in the static).

But I definitely agree about the private issue. Visible private modules 
are evil. So if you find out why private is like it is in C++, please 
let us know so we can fix those issues that cause private to be broken 
before more dams break and water seeps under the bridge.

Lucas