contravariant argument types: wanna?

[Andrei Alexandrescu]

Jérôme M. Berger wrote:
> Andrei Alexandrescu wrote:
>> Walter Bright wrote:
>>> Andrei Alexandrescu wrote:
>>>> Today D does not support contravariant arguments, but Walter told me 
>>>> once he'd be quite willing to implement them. It is definitely the 
>>>> right thing to do, but Walter would want to see a compelling example 
>>>> before getting to work.
>>>
>>> The stumbling block to contravariant parameters (not arguments) is 
>>> how it throws a monkey wrench into the overloading rules. The problem 
>>> is deciding if a function overrides or overloads, when its parameter 
>>> types are different.
>>>
>>> The current rule is simple: if the parameter types are identical, it 
>>> overrides. If they are not identical, it overloads.
>>
>> I don't see that as a huge problem. First off, right now the override 
>> keyword is required (and for good reason, I might add). Second, the 
>> new rule is simple: if the overriding function can be called with the 
>> overriden function's arguments, it is overriding it. True, things get 
>> more complicated when the base class also defines a corresponding 
>> overload:
>>
>> class A {
>>     void fun(A);
>>     void fun(B);
>> }
>>
>> class B : A {
>>     override void fun(A);
>> }
>>
>     This is poor design since it involves crossed dependencies. The 
> ancestor should never be aware of the derived classes. Therefore, I vote 
> for it to be an error.

The only reason for which I used A and B in the arguments list was to 
reduce the number of types defined. You may want to replace the two in 
the arguments list with X and Y.

Andrei