[dmd-beta] dmd 2.063 beta 3

[Rainer Schuetze]

On 18.05.2013 21:51, Walter Bright wrote:
>
> On 5/18/2013 12:28 PM, Andrej Mitrovic wrote:
>> On 5/18/13, Walter Bright <walter at digitalmars.com> wrote:
>>> I don't agree. A base class's scope must override the top level module
>>> scope.
>>>
>>> Also, a base class can always override what a derived class does.
>>> This is
>>> not hijacking.
>> Don't you see that this change in behavior is going to surprise a lot
>> of people? It's intuitive to me that this is going to cause trouble
>> down the road. A base class could be in another file, in another
>> library, and if the library writer decides to introduce a scoped
>> import, suddenly the user's code might end up calling the wrong
>> function (if the type signatures are the same the user will have *no
>> idea* what happened). This is the definition of function hijacking.
>>
>> If it is a feature, it is not properly documented, and I can't tell
>> which pull request changed the behavior so I don't know whether to put
>> it in the changelog or not.
>>
>> Kenji, maybe you know?
>>
>
> 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.