cat > bug.d << CODE
class Base
{
int param;
}
class Foo(int param) : Base
{
int val()
{
return param; // <-- param refers to super.param
}
}
unittest
{
auto foo = new Foo!12;
assert(foo.val() == 12);
}
CODE
dmd -unittest -main -run bug
----
Comment #1 by yebblies — 2013-11-20T03:34:48Z
That's interesting. Would you still expect the template parameter to have priority in the expanded case?
template Foo(int param)
{
class Foo : Base
{
int val()
{
return param; // <-- param refers to super.param
}
}
}
Comment #2 by code — 2013-11-20T13:35:22Z
(In reply to comment #1)
> That's interesting. Would you still expect the template parameter to have
> priority in the expanded case?
>
> template Foo(int param)
> {
> class Foo : Base
> {
> int val()
> {
> return param; // <-- param refers to super.param
> }
> }
> }
Well, it's the same example but it's easier to argue for the current behavior in the explicit template form.
The bug is that this allows to silently break valid code by changing the base class definition.
I don't think that it's sane to give the base class scope a higher priority than any other scope. That is, the same hijack protection that works when importing two module scopes should work for base class+module, base+interface and maybe even base+alias this, and alias this+module.
So I would expect "Base.param at bug.d(3) conflicts with param at bug.d(6)".
Comment #3 by robert.schadek — 2024-12-13T18:12:13Z