import std.stdio;
void main()
{
b v=new b;
v.f;
v.a.f;
(&v.f)();
(&v.a.f)();
}
class a
{
void f()
{
writeln("class a");
}
}
class b:a
{
void f()
{
writeln("class b");
}
}
This program write:
class b
class a
class b
class b
Comment #1 by smjg — 2007-11-08T08:04:03Z
What is v.a and where's it documented? Should it work?
Comment #2 by smjg — 2008-09-09T14:56:21Z
Since I can't at the moment find any evidence in the spec that v.a is a valid expression, I'm marking this as accepts-invalid. If I'm wrong, please show me where it's defined.
Comment #3 by jarrett.billingsley — 2008-09-09T15:17:33Z
(In reply to comment #2)
> Since I can't at the moment find any evidence in the spec that v.a is a valid
> expression, I'm marking this as accepts-invalid. If I'm wrong, please show me
> where it's defined.
>
a is the class a, which for some reason is accessible through a reference to class b. If you capitalize the class names it makes it a lot clearer.
I think it might actually be somehow related to the thing about typeof(this) and non-virtual calls made on the expressions page:
http://www.digitalmars.com/d/1.0/expression.html
In any case it doesn't seem to be explicitly documented, but I wonder if there's a use for it. It breaks encapsulation by allowing you to manually access a base class's implementation of a method, and with single inheritance there's no need to select the implementation from several base classes.
Comment #4 by k.hara.pg — 2011-06-18T02:40:54Z
It seems to me that sample code is valid.
Because dmd frontend has v.a as DotTypeExp explicitly and keeps its information,
then resolve overloads of f as A.f.
Therefore v.a.f should call A.f is right (but not documented) behavior.
-> Remove 'accepts-invalid' from keywords.
And generated code from (&v.a.f)() calls B.f is wrong-code.
It should be fixed.
Comment #5 by smjg — 2011-06-18T02:59:01Z
(In reply to comment #4)
> It seems to me that sample code is valid.
> Because dmd frontend has v.a as DotTypeExp explicitly and keeps its
> information,
a is not a member of v. So the expression is invalid. Unless you can find something in the spec that states otherwise.
> then resolve overloads of f as A.f.
> Therefore v.a.f should call A.f is right (but not documented) behavior.
> -> Remove 'accepts-invalid' from keywords.
How can a case of the compiler accepting something that the spec doesn't allow be neither accepts-invalid nor a spec issue?
Comment #6 by bugzilla — 2011-06-28T12:45:57Z
v.a is supposed to work, and it means look up the name in the scope of the base class a.
Comment #7 by smjg — 2011-06-28T13:00:09Z
(In reply to comment #6)
> v.a is supposed to work, and it means look up the name in the scope of the base
> class a.
Nice try. Now supply a link to the relevant bit of the spec.
Comment #8 by bugzilla — 2011-06-28T13:28:55Z
(In reply to comment #7)
> (In reply to comment #6)
> > v.a is supposed to work, and it means look up the name in the scope of the base
> > class a.
> Nice try. Now supply a link to the relevant bit of the spec.
If it's not in the spec, it needs to be. Wanna do a pull request?