[dmd-beta] dmd 2.063 beta 3

[Kenji Hara]

2013/5/19 Rainer Schuetze <r.sagitario at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20130519/4b60c18a/attachment.html>