Walter: Import clarifications.

[Bruno Medeiros]

As part of the effort to develop an Eclipse D IDE, I've been planning to 
create some amount of D-semantic-aware IDE functionality. Right now I've 
been working on an Open Definition like feature, and I've come across 
some issues I would like to have clarified, namely in regards to D 
import behavior.
The issues are as follow, and I've tested the following cases with the 
current DMD implementation, but I've just wanted to check if their 
behavior is indeed the intended behavior, since I don't think any of 
them are clearly defined in the D spec.
(these might also be some good points to clear up in the spec)

#1 : Automatic self module FQN availability
A module declaration makes the module fully qualified name available?
-----    -----
module pack.mod;

alias pack.mod mymod;
// OK because FQN "pack.mod" is automatically available?

alias mod mymod2;
// Fails because "mod" not available, correct?
-----    -----
The following is allowed however:
-----    -----
module writefln; // Notice the module name
import std.stdio;

void func() {
	writefln("SSS");
}
-----    -----
suggesting that the module name has less priority that the names in the 
module scope, even those from imports (ie, the secondary/background 
namespace). Correct?


#2 : FQN names are always publicly imported
-----    -----
module pack2.fooprivate;

int fooprivateImportVar;

-----    -----
module pack.sample;

import pack2.fooprivate; //Here we privately import the previous module

-----    -----
module test;
import pack.sample;

void func() {
   // And so fooprivateImportVar is not accessible
   //fooprivateImportVar++;

   // However the FQN names from the private import are accessible:
   alias pack2.fooprivate myfooprivate; // ok
   pack2.fooprivate.fooprivateImportVar++; // ok
   // Correct?
}


#3 : Chained FQNs
-----    -----
module pack2.foopublic;

int foopublicImportVar;

-----    -----
module pack.sample;

public import pack2.foopublic; // Here we have a public import

-----    -----
module test;
import pack.sample;

void func() {
   pack.sample.pack2.foopublic.foopublicImportVar++;
   // One can access an FQ name, chained from another one?? Correct?
   // (This one is damn ugly IMO)
}

#4: Selective import and alias import bring names to the primary 
namespace, and not the secondary namespace?
That is, if you have this:
   import mystdio = std.stdio;
   import std.stdio : writefln;
Then both 'mystdio' and 'writefln' will be first-class names in the 
scope (and will immediately conflict with other existing names), unlike 
the names imported by normal "content" imports, which go into the 
secondary/background namespace, and only conflict if referenced, correct?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D