Import concerns revisited

[Dave]

Walter Bright wrote:
> Ivan Senji wrote:
>> There should be a big difference (if I understand things correctly):
>> A simple example:
>>
>> If I have:
>>
>> module m1;
>>
>> int func(){return 1;}
>>
>> and
>>
>> module mainmodule;
>>
>> import m1;
>>
>> void main()
>> {
>>   writefln(func());
>>   writefln(m1.func());
>> }
>>
>> there are no problems with that!
>>
>> But if I add:
>>
>> module m2;
>>
>> int func(){return 2;}
>>
>> and change mainmodule to:
>>
>> import m1;
>> import m2;
>>
>> void main()
>> {
>>   writefln(func());     //<- conflict
>>   writefln(m1.func());
>>   writefln(m2.func());
>> }
>>
>> And suddenly I get a lot of conflicts.
> 
> I agree, but the "static import" resolves that.
> 
> 
>> Sure there is a way to solve it by adding:
>>
>> alias m1.func func;
>>
>> And then use m2.func to use func from m2.
>>
>> But what if I wanted to give m2.func a totally different name to avoid
>> confusion, i can try to add this:
>>
>> alias m2.func someOtherName; instead of alias m1.func func;
>>
>> But then once again I would get an error about a conflict:
>>
>> Once again there is a solution:
>>
>> alias m1.func func;
>> alias m2.func f2;
>>
>> And it works OK, but the intention here is a bit hidden.
>>
>> Conclusion:
>>
>> import m2.func as f2;
>>
>> is not the same as:
>>
>> import m2;
>> alias m2.func f2;
>>
>> but is equivalent to:
>>
>> import m2;
>> alias m2.func f2;
>> //insert here a possibly huge number of aliases to avoid conflicts of
>> m2.func with func from other imported modules.
> 
> If "static import" is used, there aren't any conflicts.
> 
> There are two issues here:
> 
> 1) the "second class name lookup" characteristic of import.
> 2) inserting a name from one scope into another (possibly renaming it in 
> the process)
> 
> static import does (1) by importing but disabling the second class lookup.
> alias does (2).

Walter, I think what most are getting at here is that the 'as' syntax 
just seems cleaner and more efficient from a coding and maintenance POV.

If it's easy to implement, then I say go for it. If nothing else, people 
can still use 'explicit' aliasing. I argue that 'as' will actually be 
quicker for newbies to grasp (*especially* when they see it in example 
code), and my sense is that it will be a boon to maintenance because it 
generally won't end-up buried in the middle of a module like many 
aliases would be. It's not like alias will be a wasted feature - most 
prominently it will be used for storage types; it just feels more 
'natural' that way.