There are quite a few questions & answers about hacking around the limitation of C# not allowing method return (and argument) types to be changed to compatible types on
Eric Lippert already answered this way better than I could.
Check out his series on Covariance and Contravariance in C#
and
How does C# 4.0 Generic Covariance & Contra-variance Implmeneted?
EDIT: Eric pointed out that he doesn't talk about return type convariance but I decided to keep the link in this answer because it is a cool series of articles and someone might find it useful if looking up this topic.
This feature has been requested and almost 5 years ago Microsoft has responded with "Thanks for logging this. We hear this request a lot. We'll consider it for the next release."
And now I'll quote Jon Skeet because it would not be a proper answer on StackOverflow without an answer by Jon Skeet. Covariance and void return types
I strongly suspect that the answer lies in the implementation of the CLR rather than in any deep semantic reason - the CLR probably needs to know whether or not there's going to be a return value, in order to do appropriate things with the stack. Even so, it seems a bit of a pity, in terms of elegance. I can't say I've ever felt the need for this in real life, and it would be reasonably easy to fake (for up to four parameters) in .NET 3.5 just by writing a converter from
Func<X>
toAction<X>
,Func<X,Y>
toAction<X,Y>
etc. It niggles a bit though :)
Seams introducing covariance of return value has no essential drawback as Java and C++ have used. However, there's real confusion cased by introducing contra-variance of formal parameter. I think this answer https://stackoverflow.com/a/3010614/1443505 in C++ is also valid for C#.
To expand on Joel's answer - the CLR has supported limited variance for a long time, but the C# compiler doesn't use them until 4.0 with the new "in" and "out" modifiers on generic interfaces and delegates. The reasons are complicated, and I would get into a mess trying to explain, but it isn't as simple as it seems.
Re making a "protected internal" method into a "public" method; you can do this with method hiding:
public new void Foo(...) { base.Foo(...); }
(as long as the arguments etc are all also public) - any use?
It does, you just have to wait for VS2010/.Net 4.0.
This answer is not talking about C#, but it helped me understand the issues better and maybe it will help others: Why is there no parameter contra-variance for overriding?