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