On Feb 22, 2016, at 6:11 PM, Jonathan M Davis via dmd-internals <dmd-internals@puremagic.com> wrote:


But particularly given the implentation, the namespacing of imports gets a
bit weird. What I would have normally expected would be that an import makes
it so that you can use all of the symbols that it imports in the current
scope - either with just their name or their FQN, and if there's a conflict,
you're forced to use their FQN. Selective imports then just restrict which
symbols get imported from a module (but don't change the semantics
otherwise), and static imports are used for those cases where there would be
too many symbol conflicts between two or more modules, and you need to force
FQN to make it work cleanly. None of that way of thinking about really
involves merging namespaces or anything like that. The implementation, on
the other hand, seems to be merging lists of symbols together as if they
were all in the same module when you import them, and that makes for a very
different way for them to function - one that I don't find intuitive at all.

This exact behavior can be had like this:

static import foo;
import foo: symbol1;

Now symbol1 is mapped to foo.symbol1, and you can also use any FQN from foo.

Note that at the moment selective imports cannot be combined with static, this is an error:

static import foo: symbol1;

We could potentially allow this to be the combination of the above. Note that we currently allow this:

import f = foo : symbol1;

which effectively does the same thing, but renames foo to f for FQN.

I never thought I’d learn so much about D’s import system...

-Steve