On Tue, Sep 23, 2014 at 06:56:56PM +0000, Meta via Digitalmars-d wrote: > 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.
Good luck convincing Walter, then. :-( Or maybe if we can convince Andrei to twist his arm hard enough... :-P T -- Живёшь только однажды.