Local imports hide local symbols

monarch_dodra via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 23 13:19:26 PDT 2014


On Tuesday, 23 September 2014 at 20:10:35 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> Sounds reasonable. How would that be implemented, though? 
> Currently, in
> the compiler, lookup is implemented via a linked list of Scope 
> objects
> that contain, among other things, a symbol table for the symbols
> declared in that scope. A local import achieves locality by 
> adding
> symbols to the current (i.e., innermost) Scope, since doing 
> otherwise
> would cause those symbols to "spill" into the outer scopes and 
> they will
> persist past the lifetime of the current scope.

Arguably, that's not my problem...

> OTOH, it's this importing into the innermost scope that causes 
> this
> issue to begin with, since by definition, the innermost scope 
> takes
> precedence over outer scopes, so the imported symbols would 
> shadow
> symbols declared in outer scopes.

I think that's the issue here. Are we actually importing "into" 
the innermost scope, while shadowing any previous imports?

AFAIK, that's a behavior which is reserved for selective imports.

As I said, local imports, IMO, should behave in all aspects as a 
global import. It simply only exists during its scope, but is not 
actually any more "internal" than the rest. If a local import 
creates a symbol ambiguity, then it's ambiguous, and compilation 
ceases. I think that's the behavior we should be going for.

> Implementing what you suggest would either involve treating 
> imported
> symbols separately (by having multiple parents per scope, which 
> quickly
> devolves into a mess, or otherwise having sibling pointers to 
> imported
> scopes, which also greatly complicates lookup logic), or 
> sticking
> symbols into outer scopes and keeping track of which symbols 
> were
> imported where so that they can be removed after we leave the 
> current
> scope -- which is fragile and would again add tons of 
> complications to
> the compiler.
>
>
> T

Unfortunately, I don't know how the compiler works.


More information about the Digitalmars-d mailing list