John Reimer wrote:
> I've seen this error also on several occasions.  I can't remember the exact source of it, but I think it's related to another issue.  It was my understanding that that was due to public imports somewhere up the line. This might have been one of the reasons why discussions started concerning a borked import system.  Perhaps I'm wrong?

How imports work is that first a name is searched for in the current namespace. If it is not found, then it is looked for in the import list. If it is found uniquely among the imports, then that is used. If it is in more than one import, an error occurs:

--- module A ---
void foo();
void bar();

--- module B ---
void foo();
void bar();

--- module C ---
import A;
void foo();
void test()
{ foo(); // C.foo() is called, it is found before imports are searched
  bar(); // A.bar() is called, since imports are searched
}

--- module D ---
import A;
import B;
void test()
{ foo();   // error, A.foo() or B.foo() ?
  A.foo(); // ok, call A.foo()
  B.foo(); // ok, call B.foo()
}

--- module E ---
import A;
import B;
alias B.foo foo;
void test()
{ foo();   // call B.foo()
  A.foo(); // call A.foo()
  B.foo(); // call B.foo()
}

And that's all there is to it. If you always used FQNs, you'll never run into any collision or ambiguity issues.

> Er.. that tells me more that there's a problem with the original mechanism. And "static import" is a workaround.  Why not fix the original import system?  There must be something wrong with it.  So are we adding new constructs to workaround name clashes? Is that a good idea?  Is that the reason 'static import' was suggested?  There shouldn't be name clashes when fully qualified names are used in the first place!

There aren't any name clashes if you use FQN's.


>> Which is not to say that I'm favouring 'static import' in this discussion, I'm simply saying that all of the proposals, including static import, are an *enormous* improvement over what we have now.

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.

Then in steps alias, which can be used to selectively bind import symbols into the current module namespace.

Bill Baxter wrote:
> In article <e8vife$14p6$1@digitaldaemon.com>, Walter Bright says...
> 
>> (*) And yes, you can still access the other names in the static import via FQN's. A couple posters thought that might be a problem, but:
>> 1) I doubt many are going to accidentally type in a FQN;
>> 2) FQN's are not going to produce name collisions unless you happen to name your symbols the same as the topmost package name, which is just not realistically going to be a problem.
> 
> Does that mean if I do
> 
> static import std.string;
> alias std.string str;
> 
> Then there will trouble if I have a variable named 'std'?
> 
> That seems like that could be a source of trouble to me.  But maybe I've
> misunderstood what you're saying.

The code:

  int std;
  import std.string;

Gives:

  test.d(2): import test.std conflicts with test.std at test.d(1)

Just like you can't do:

  int std;
  long std;

> The imports can be placed anywhere in the module, even (ugh) inside class definitions. 'import' isn't any easier to search for than 'alias'.

I was wondering - is there any good reason to allow imports everywhere?

OT: if you'll be changing the import system, _PLEASE_ make private imports the default.


xs0

kris wrote:
> The same thing happened with Associative Arrays: you didn't bother to solicit opinion on either of the two occasions when it was changed; and then subsequently complained when people still found issue with you alternate changes. It's still not right to this day. I see the same pattern here. And for what?

I did implement it according to the suggestions - and then the people who made those suggestions had issue with it. So I take issue(!) with your statement that I did it in a vacuum. I preferred the original design, and the change caused me a lot of work updating things like dmdscript which extensively used AA's.


> Anyone would think we were trying to sabotage the language,

Nobody thinks that. We are all trying to get the best design for D possible. That doesn't mean we are all going to agree on what the best design is. There's no cause to label a difference of opinion as sabotage, or any of the other epithets bandied about in this disagreement (or some of the previous ones).

Lars Ivar Igesund wrote:
> I personally don't like it myself, first of all it is not a natural word for
> me (I don't have English as my mother tongue, might very well be the
> reason), but my understanding of the word make it very unlikely to me that
> it actually _do_ something, it should just give something a different name.
> Using it for anything else (pulling something from one namespace to
> another, for instance when subclassing), or for making namespaces, is to me
> the most unintuitive thing I've ever come across in a programming language
> (I don't count COBOL here ...). I actually hate it :)

It does give something a different name, in the current namespace. You could think of it like what Python calls it: binding a name from another namespace into the local symbol table.

Or you could think of it like a 'reference' variable, such as inout function parameters.

Walter Bright wrote:

> Lars Ivar Igesund wrote:
>> I personally don't like it myself, first of all it is not a natural word for me (I don't have English as my mother tongue, might very well be the reason), but my understanding of the word make it very unlikely to me that it actually _do_ something, it should just give something a different name. Using it for anything else (pulling something from one namespace to another, for instance when subclassing), or for making namespaces, is to me the most unintuitive thing I've ever come across in a programming language (I don't count COBOL here ...). I actually hate it :)
> 
> It does give something a different name, in the current namespace. You could think of it like what Python calls it: binding a name from another namespace into the local symbol table.
> 
> Or you could think of it like a 'reference' variable, such as inout function parameters.

Yes, I could, because those (especially bind) are much better words for what
actually happens.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

xs0 wrote:
>> The imports can be placed anywhere in the module, even (ugh) inside class definitions. 'import' isn't any easier to search for than 'alias'.
> I was wondering - is there any good reason to allow imports everywhere?

It's usually a good idea to make things as orthogonal, with as few special case, as possible. Since imports are a declaration, they should work wherever declarations work.

> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.

It's too late for that, sorry. Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier.

Walter Bright wrote:

> xs0 wrote:
>>> The imports can be placed anywhere in the module, even (ugh) inside class definitions. 'import' isn't any easier to search for than 'alias'.
>> I was wondering - is there any good reason to allow imports everywhere?
> 
> It's usually a good idea to make things as orthogonal, with as few special case, as possible. Since imports are a declaration, they should work wherever declarations work.
> 
>> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.
> 
> It's too late for that, sorry. Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier.

Well, who did ever say that was a good idea, everything public by default? ;) And nothing is ever too late :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Sean Kelly wrote:
> ...
> FQN).  And C is simply too antiquated/low-level to consider.  I'm not aware of how Java or C# operate in this context however.  I don't suppose anyone with more experience could comment?
> 
> Sean

For C# it's FQN by default, but if you add the "using" keyword it brings it into the local namespace. If there is a collision you have to use the FQN.

Lucas

Walter Bright schrieb:
> It's too late for that, sorry. Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier.

I don't think so. Where are the millions lines of code, that would break? At the moment, this is an issue that is against writing them.

Making things private is a defensive change. You can solve every problem with adding 'public' and the compiler will tell you every problematic place. Other is the default public. The modules writer does no get problems, but the user of the module will can get them from a implementation detail.