1570 – Wrong return for address operator

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

What is v.a and where's it documented? Should it work?

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.

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

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.

(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?

v.a is supposed to work, and it means look up the name in the scope of the base class a.

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

(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?

Fix for compiler, not spec yet:
https://github.com/D-Programming-Language/dmd/commit/2d8f2c76d514e56ccef0f8e77e844f0093c7c4ff
https://github.com/D-Programming-Language/dmd/commit/2c491bcd6bdf482a212b8ef28bb73cdfa6b60155 

Commit pushed to https://github.com/D-Programming-Language/d-programming-language.org
https://github.com/D-Programming-Language/d-programming-language.org/commit/9d331033cfa109d8b44e687803cbbbbfc4f4bfe2
fix Issue 1570 - Wrong return for address operator