Import concerns revisited

[Dave]

Walter Bright wrote:
> David Medlock wrote:
>> Derek Parnell wrote:
>>
>>>
>>> I'm hope I'm not messing up Kris' words here but I think he is saying 
>>> that  we need to cut down on the amount of typing and reading people 
>>> *must* do  in a program. Keep it to a minimum. Try and work the 
>>> syntax so that the  common and mandatory things are short, easy, and 
>>> intuitive to do. Make the  unusual and 'special' things have more 
>>> detail in the syntax.
>>>
>>
>> I 100% agree.  The usual cases should be implicit, and the corner 
>> cases explicit.
> 
> 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.

I'm not sure what exactly Kris said, but imports are ubiquitous. Not 
used as much as loops of course, but they are used in every program.

The goto also kind of equates with 'alias' in that goto's and alias's 
will be stuck almost anywhere in the code while (by convention) imports 
are at top. So there's an encouragment of good coding practices and 
maintenance element to this too.

> 
> 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 agree, but this will be a major convenience, imho.

The proposal here

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39967
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39973

seems to meet this criteria:

a) address all of Kris' concerns (if not Kris, pipe in here).
b) backward compatible.
c) can be implemented w/o significanly changing the current compiler (I 
think) other than for the import statement additions.
d) is consistent with how import + alias works now.
e) are a significant convenience.
f) keep the visual continuity of import statements for maintenance purposes.
g) encourage good coding practices with regards to imports and aliasing.

- Dave