http://ftp.digitalmars.com/dmd2beta.zip

This has Kenji's new 'transition' switch.

Regressions:

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 18.05.2013 01:34, Walter Bright wrote:
> http://ftp.digitalmars.com/dmd2beta.zip
>
> This has Kenji's new 'transition' switch.
>
> Regressions:
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

I just updated to the current master after a few weeks of keeping it stable for the Visual D release, and noticed that the lookup rules for local imports seem to have changed:

void remove(int x)
{
}

class Boo
{
	import core.stdc.stdio;
}

class Foo : Boo
{
	void foo()
	{
		remove(1);
	}
}

dmd 2.062 compiles just fine, master "dmd -c test.d" now returns:
test.d(14): Error: function core.stdc.stdio.remove (const(char*) filename) is not callable using argument types (int)

i.e. the local import in the base class has higher precedence than module scope. Is this change by design or a regression? I didn't find anything about it in the changelog.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/18/13, Rainer Schuetze <r.sagitario@gmx.de> wrote:
> i.e. the local import in the base class has higher precedence than module scope. Is this change by design or a regression?

That had to have been a regression. It's basically allowing function
hijacking via imports. I think we should file this as a bug.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/18/2013 7:11 AM, Andrej Mitrovic wrote:
> On 5/18/13, Rainer Schuetze <r.sagitario@gmx.de> wrote:
>> i.e. the local import in the base class has higher precedence than
>> module scope. Is this change by design or a regression?
> That had to have been a regression. It's basically allowing function
> hijacking via imports. I think we should file this as a bug.

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.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/18/13, Walter Bright <walter@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?
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Sat, 18 May 2013 21:28:55 +0200
Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 5/18/13, Walter Bright <walter@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.

Wouldn't it just generate a "function call matches multiple functions"
error? If not, it definitely *should*, at least assuming that
inheriting imports should even be allowed at all. I can see how
inheriting imports *might* be considered potentially useful (inherit a
class and everything you need to deal with it is already imported), but
the usefulness does still seem questionable to me, and it does seem
counter-intuitive.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/18/2013 12:28 PM, Andrej Mitrovic wrote:
> On 5/18/13, Walter Bright <walter@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.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/18/13, Nick Sabalausky <bus_dmdbeta@semitwist.com> wrote:
> Wouldn't it just generate a "function call matches multiple functions" error? If not, it definitely *should*.

It seems it doesn't:

-----
import std.stdio;

void remove(const(char*) filename)
{
    writeln("here");
}

class Boo
{
    import core.stdc.stdio;  // try commenting out
}

class Foo : Boo
{
    void foo()
    {
        remove("");
    }
}

void main()
{
    auto f = new Foo;
    f.foo();
}
-----
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

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@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.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/18/2013 1:30 PM, 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.
>
> 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.


The current behavior is consistent with the D lookup and scoping rules. I believe it is better to have a consistent rule than one that has a lot of arbitrary cases in order to be more intuitive - my experience with that is people never to figure out what those arbitrary rules are, they just poke at random until it works (see C++ overloading rules for a fine example).
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta