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.
