Overloading/Inheritance issue

[Steve Schveighoffer]

Derek Parnell Wrote:

> This is intentional and is due to D's simplistic lookup rules. Basically, D
> will look for a matching signature only in the class it self and not in any
> parent classes (its a little more complex than this but ...)

OK, I sort of saw this in the language specification, but I wasn't sure if it covered my case (in fact I tried an alias and it failed to compile, but I now see it was because I had a syntax error in my file.  Trying it now works).

So my concern here is that the given behavior does not gain anything, but just serves as an annoyance. Here is a scenario which I think could realistically happen:

Let's use the same examples of X and Y.  Let's say X, along with providing useful implementations of foo() and foo(int), provides another method bar(), which performs some other useful stuff.  A coder thinks of some new way to do bar(), and so derives a class Y from X, which then provides the new implementation of bar(), but leaves X's implementation of foo() and foo(int) to the base class.

People love the new Y class, and so start using it in all their projects.  Later on, the coder who implemented Y, finds another way of implementing foo(int), but thinks foo() cannot be improved.  So he releases a new version of Y which overrides only foo(int).  Now code that calls foo() from a Y derivative all breaks because the coder added a foo(int) method.  Everyone who used the Y derivative suddenly finds their code doesn't compile.

This is very counterintuitive.  Not only that, but I could easily see it slipping through unit tests.  Who thinks to unit test a class by calling all the base class members they didn't override?

My point basically is why should a coder be forced to declare an alias when realistically there is no reason they would NOT want to declare the alias?

-Steve