Symbol lookup rules and imports

[H. S. Teoh via Digitalmars-d]

On Mon, Dec 08, 2014 at 12:34:07AM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/2/2014 2:00 PM, H. S. Teoh via Digitalmars-d wrote:
> >However, there are major issues with scoped imports currently,
> >that make this otherwise ideal solution less-than-ideal, which stem from
> >the way 'import' is implemented in D. When the compiler encounters an
> >'import' statement, what it essentially does is to parse the symbols in
> >the target module, and add them to the symbol table for the current
> >scope.
> 
> No, it does not. Each scope has a symbol table of symbols declared in the
> current scope,
> 
>   https://github.com/D-Programming-Language/dmd/blob/master/src/dsymbol.h#L298
> 
> and it has an array of imported symbol tables:
> 
>   https://github.com/D-Programming-Language/dmd/blob/master/src/dsymbol.h#L301
> 
> Only if the symbol is not found in the current scope,
> 
>   https://github.com/D-Programming-Language/dmd/blob/master/src/dsymbol.c#L902
> 
> it then looks in the imported symbol tables:
> 
>   https://github.com/D-Programming-Language/dmd/blob/master/src/dsymbol.c#L910

I realize that my understanding on the workings of dmd may not be quite
accurate, and I apologize for any inadvertent misrepresentations, but
the fact remains that the current behaviour of import is very
counterintuitive, and users will continue having issues with it if the
current state of things continue to hold.

Having imported symbols shadow symbols in outer lexical scopes, while it
may make sense in implementation, is a very counterintuitive behaviour.
It means unrelated modules can hijack symbols from outer lexical scopes
with no indication whatsoever -- if you `import external_lib` today,
everything may work fine, but upon upgrading external_lib to a new
version, suddenly one of your outer lexical symbols is hijacked without
any warning.

Having private symbols conflict with public ones is also very
counterintuitive and frustrating behaviour -- even if the underlying
cause is different, it's perceived as a related issue.

Having scoped imports at module scope leak symbols to importers of the
module is also very counterintuitive.

Having symbols imported at struct scope visible via S.symbol is
extremely counterintuitive, though I believe Kenji has already submitted
a PR for this. (Thanks, Kenji!!)

And so on. These may be genuine bugs, or design flaws, or an oversight,
but whatever the cause, the result is the same fly in what could
otherwise have been a tasty soup of a nice module system.


T

-- 
One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"