Import conflict resoultion

[Jeremy]

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 :)

>
>I personally like the last because it's the most visually distinctive 
>(makes it hard to miss the alias) and it represents exactly what is 
>going on, but whatever.
>
>I agree there would be no need to prevent FQN access. So there would be 
>no need to allow 'import std.string = std.string;' to force the FQN to 
>use the original name.
>
>Ergo, the current implementation of alias along with the Walter's 
>'static import' could be used to implement this type of syntax (internal 
>to the compiler) I believe.
>
>> But really, I'll be happy just as long as we're not left with only #1 
>> and #2. I'm delighted that this fundamental issue is finally getting 
>> attention; I'm disappointed at how heated the discussion became.
>> 
>> Thanks again, Regan.

- Jeremy