Hopefully I have something new to add to the argument

[Sean Reque]

Thanks for the links! I was able to find through it two very long discussions on this issue. One point that was brought up is that the reason D implements overload resolution the way it currently does is because c++ did it the same way for 20 years and no one complained. Well, a lot of post were made about different aspects of the issue, so I want to just focus on the area I have the biggest problem with. I didn't read EVERY post, but I hope this is a newer way of looking at it. The following C++ program compiles fine:

#include <stdio.h>
class A {
	public:
	void print(int i) {
		printf("you gave me integer %d\n", i);
	}
};

class B : public A {
	public:
	void print(char c) {
		printf("you gave me character %c\n", c);
	}
};

void overload_res_test(A& a) {
	a.print(1);
}

int main() {
	B b;
	overload_res_test(b);
	return 0;
}

The following --equivalent-- D program crashes with a runtime exception that can  be debugged as far as I know with a debugger:

class A {
	public:
	void print(int i) {
		printf("you gave me integer %d\n", i);
	}
}

class B : A {
	public:
	void print(char c) {
		printf("you gave me character %c\n", c);
	}
}

void overload_res_test(A a) {
	a.print(1);
}

void main() {
	scope B b = new B();
	overload_res_test(b);

}

Like I said in my first post, I had to spend a long time getting a debugger to work when I tried compiling a hello world app with gtkD and I got a hidden function error. The shadowed method declaration was about 7 classes up the hierarchy, while the actual function that did the shadowing was about 3 or 4 up the hierarchy. The worst part about this is that the error is only revealed at runtime and only if the function is called under certain conditions. For a strongly-typed compiled language, in my opinion this is disastrous, and it's not what either C++ or Java does.