2013/5/19 Rainer Schuetze <r.sagitario@gmx.de>
On 18.05.2013 21:51, Walter Bright wrote:
I agree that it is changing behavior, and should be properly documented.
However, I also believe it is correct behavior and fixed a bug.

It's *always* true that when you change a base class, you affect the
derived classes.

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.

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.

Hmm, in module level, import declaration will add name lookup path _in private_.

module a;
import std.algorithm;   // default is private

module b;
import a;
void main() {
    [1,2,3].map!(a=>a);  // Error: no property 'map' for type 'int[]'
}

But with current master, import declaration in base class member adds name lookup path _in public_.
I had not recognize this behavior.

class A {
    import std.algorithm;  // default is public!?
}
class B : A {
    void test() {
        auto r = [1,2,3].map!(a=>a);    // succeeds to compile
    }
}
void main() {
    auto r = B.map!(a=>a)([1,2,3]);    // also succeeds to compile
}

I think this is inconsistent, and class case should be fixed.

Kenji Hara