Proposition for change in D regarding Inheriting overloaded methods

[Walter Bright]

Steven Schveighoffer wrote:
> I still would like a real example of how this is desirable.

When author A wants to extend the API of A without silently breaking 
derived B of which author A has no knowledge of.

>>> If the author really didn't want to expose "foo(char[])" then why were 
>>> they deriving their class from A?  It goes against the whole idea of 
>>> inheritance, doesn't it?
>> The problem is when the base class implementor wants to add some 
>> functionality (or specialization) with a new overload. A's implementor may 
>> be a third party, and has no idea about or control over B. His hands 
>> shouldn't be tied.
> 
> This argument is absurd.  How is the author of A's hands tied?  If author A 
> changes his API, author B had better take notice.

The problem is, author A adds to (not changes) his API, and B starts 
silently failing. No compile error, no runtime error.

> What if author A decides 
> to change the way he stores protected data?  How can you prevent author B 
> from having to understand that?

Author A should be able to *add* methods and fields to his API without 
possibly causing silent breakage of derived classes. It is ok to cause 
them to break with a compile or runtime error, but not ok to silently 
break them.

If author A *changes* his API, that's a different thing entirely.

> Even with your exception solution, A can break code which uses instances of 
> B by adding an overload.

It won't be silent breakage, though. The evil is in the *silent* 
breakage. The author A shouldn't have his hands tied preventing him from 
adding to his API out of fear of silently breaking his customers' code.