Import conflict resoultion

[Dave]

Jeremy wrote:
> In article <e95lvr$2t28$1 at digitaldaemon.com>, Dave says...
>> Don Clugston wrote:
>>> Regan Heath wrote:
>>>> Proposed solutions
>>>> ------------------
>>>> 3:
>>>> Prevent import into the "secondary namespace", only allow FQN access. 
>>>> (AKA "static import")
>>>> static import std.string; //exact syntax may vary
>>>> static import std.regexp; //exact syntax may vary
>>>>
>>>> ..find(.. //error
>>>> ..std.string.find(.. //ok
>>>> ..std.regexp.find(.. //ok
>>>>
>>>> "All 'static import' does is eliminate the "if the name is not found 
>>>> in the current module, look in the imports" step. This has the effect of
>>>> requiring the use of FQN's when referencing imports."
>>>>  - Walter
>>>>
>>>> 4:
>>>> Import into a custom namespace, eg.
>>>> import std.string str; //exact syntax may vary
>>>> import std.regexp;
>>>>
>>>> ..str.find(.. //calls std.string.find
>>>> ..find(.. //calls std.regexp.find
>>>>
>>>> This method should also prevent import into the "secondary namespace".
>>>
>>> Thanks, Regan. Indeed this is an attempt at conflict resolution in both 
>>> meanings. Well done.
>>>
>>> Seems to me that one of Walter's key non-negotiables is to ensure that:
>>> ------------
>>> import std.stdio;
>>>
>>> void main()
>>> {
>>>    writefln("Hello, world!");
>>> }
>>> ------------
>>> still works. Hopefully all of us can see the importance of that.
>>>
>>> Personally, I don't have a strong objection to #3, if it was combined 
>>> with default private imports, we wouldn't have to type "private static 
>>> import" all the time, which would IMHO be unacceptable.
>>>
>>> However, unlike Kris, I don't have any experience with working with 
>>> really large projects in D (or any language at all, actually) -- so I'll 
>>> trust Kris on the need for #4.
>>>
>>> #4 would definitely need different syntax, with a clearer visual 
>>> distinction from a traditional import. Whether it be "import alias 
>>> std.string str;" or "import std.string as str;" or "import std.string = 
>>> str;" -- I don't have a strong preference. I don't think there would be 
>>> any need for it to prevent FQN access.
>>>
>> import std.string as string; // Ok, but new keyword
> 
> I like this one the best. It is so "readable" while not being too wordy.
> 
>> import string = std.string; // Ok: concise, distinct, consistent and 
>> logically accurate.
> 
> That just looks odd to me... it looks like "import" is some data type, and your
> assigning some value "std.string" to "string". It also is very different from
> 'normal' import lines:
> 
> import std.string;
> import std.string as str;
> 
> vs.
> 
> import std.string;
> import str = std.string;
> 
> Putting "as str" at the end of the import is more intuitive than putting a "str
> =" in the middle of the import line... 
> 
> disclaimer: add IMHO to all my statements :)
> 

Seems others agree with you - note your preferences here if you want:

http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution