Local imports hide local symbols

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 23 12:06:26 PDT 2014


On 9/23/14, 12:01 PM, H. S. Teoh via Digitalmars-d wrote:
> 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

This is a gaping hole that gets worse by the minute. We must fix it with 
the next release. -- Andrei



More information about the Digitalmars-d mailing list