***** D method override mechanisms borked ******

[Sean Kelly]

Bruno Medeiros wrote:
> kris wrote:
>>
>> The original behaviour limited the exposure of an overridden method to 
>> be less than or equal to the exposure of the original. For example, 
>> protected could not be made public via an override. The compiler would 
>> give you an error if you attempted to do so. The compiler used to 
>> prevent you from intercepting a superclass method where the original 
>> intent (of the designer) was that said method whould be internal usage 
>> only. For example, final, package, or private methods.
>>
> 
> If that was the original behavior, that behavior was broken. You see, 
> when overriding a method, limiting the protection level is unsafe, 
> whereas widening the protection level is safe. The protection level is a 
> call-site contract (like the return type) and as such is only safe when 
> overridden invariantly or *covariantly*.
> 
> If you designed your classes around that original behavior, they're broken.

I'm not sure I agree.  However, if overriding behaves this way then it 
makes sense that aliasing should as well, and I would be surprised if 
aliasing ever behaved this way.  Perhaps this is one area where one 
should rely on programming style and not on the compiler?


Sean