Import conflict resoultion

[Dave]

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
import std.string : string; // Ok
import std.string string; // Ok: alias-like syntax but not very distinct
import std.string = string; // wrong, = is right-assoc.
import string = std.string; // Ok: concise, distinct, consistent and 
logically accurate.

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.