Local imports hide local symbols
Meta via Digitalmars-d
digitalmars-d at puremagic.com
Tue Sep 23 11:56:56 PDT 2014
On Tuesday, 23 September 2014 at 18:52:13 UTC, H. S. Teoh via
Digitalmars-d wrote:
> I can think of a few:
>
> 1) Change lookup rules so that symbols pulled in by local
> import are
> found last. Walter has stated that he disagrees with this
> approach
> because it complicates symbol lookup rules.
>
> 2) Emit a compile error if any symbol pulled in by the local
> import
> shadows a symbol currently in scope, according to the same
> rules as
> declaring local variables that shadow identically-named
> variables in an
> outer scope within the current function body.
>
> 3) What you proposed in the bugnotes: only allow `static import
> xyz;`
> and `import xyz : a, b, c;` at local scope.
>
> As far as breakage of existing code is concerned, (1) and (2)
> will only
> break code where there was already a problem (an outer scope's
> symbol is
> being shadowed, most likely unintentionally, by the import).
> (3) will
> likely cause backlash because it will break a LOT of code that
> currently
> compiles and likely to have no actual problems. Not to mention
> that
> while naming specific symbols to import works for trivial
> cases, it can
> quickly and easily devolve into inordinately long lists of
> symbols once
> the local scope grows into non-trivial code. People are
> unlikely to be
> happy with this.
>
> Which leads to this variation of (2):
>
> 2b) Allow unqualified `import xyz;` in local scope, but only if
> NONE of
> the imported symbols shadows ANY symbol visible from that scope.
>
>
> T
The only tenable option from that list seems to be 1. 2 and 2b
either compile or not depending on the implementation details of
the module (i.e., add a symbol i to a module and it may break
code in an entirely different module that imports your module),
and 3 will break a lot of valid code.
More information about the Digitalmars-d
mailing list