[dmd-beta] dmd 2.063 beta 3

[Jonathan M Davis]

On Saturday, May 18, 2013 22:30:30 Rainer Schuetze wrote:
> I think the new behaviour is consistent with symbol lookup rules, but
> I'm not so sure about import rules. The actual case that triggered the
> issue was with the base class in a different file. Usually non-public
> imports in a module don't have an effect on another module that imports
> the module. In this case it has.

I would argue that the import would need to be _protected_ in order for 
derived classes to be affected by it if they're not in the same file. Having a 
private import affect something outside of the file that it's in violates the 
access rules.

Technically, I don't think that the idea of a protected import exists at the 
moment, but I think that it's going to have to be added if we're going to have 
imports follow the symbol lookup rules rather than simply having them restrict 
themselves to the scope that they're in lexically, which is honestly how I 
thought that they worked - the fact that they'd have any impact on derived 
types surprised me considerably.

But also, if you start following symbol lookup rules for whether local imports 
are visible or not, then you'd have to worry about public imports in a class 
affecting things in weird ways too. It seems _much_ cleaner to me to just 
restrict local imports to lexical scope, and I don't see how that would be 
inconsistent or surprising given that they're import statements, not symbols.

> Actually, I can live with it, but I cannot see a reasonable use case for
> the new behaviour. My rule of thumb would be to not use local import in
> classes. Otherwise all imported symbols are treated as static members
> with respect to lookup, hiding global functions or variables in derived
> classes.

Yeah. if importing at class scope affects anything outside of that lexical 
scope (including derived classes), I would then strongly argue that using 
class-level imports is bad practice and that if you need the import that much, 
it should be a top-level import. It's just going to cause function hijacking 
problems to have class-level imports. Function-level imports at least 
encapsulate things nicely. The class-level ones seem to be doing the opposite.

- Jonathan M Davis