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