Re: Method overrides and covariant return types

>If the current behavior is "emit the warning and then treat the method as not
>overriding anything" then I admit that the current behavior makes a lot of
>sense, because then it is reasonable to say "Yes, I wrote what I meant, don't
>show me this warning." 
>
How would you say that you don't want to see a warning for this specific 
case?

>But if the behavior is "emit the warning and then act as
>though the 'override' keyword was there" then that is a serious problem. I think
>it only makes sense to say that a method never overrides another method unless
>the 'override' keyword is present; i.e. no implicit overrides, for the reason
>you gave (directly above).
>  
>
That's the behaviour. The reason I gave is why there is a warning in the 
first place. The compiler detects that there is something going on, and 
tells you about it, asking you to solve the problem. A warning is not 
much different from an error. In both cases you should do something 
about it.

Now I think that in the long term there are two options: either we 
acknoledge that some people don't want implicit overriding, while some 
are perfectly comfortable with it, and we provide an option for users to 
chose. Or we enforce the explicit style, and then the warning can be 
made an error. The warning is just a middle ground to start with, and 
gather experience in this area.

Daniel



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click