If an interface specifies a property or method to return another interface, why is it not allowed for implementations of the first interface to "change" the return type into a more specific type?
Let's take an example to illustrate:
interface IFoo
{
IBar GetBar();
}
interface IBar
{ }
class Foo : IFoo
{
// This is illegal, we are not implementing IFoo properly
public Bar GetBar()
{
return new Bar();
}
}
class Bar : IBar
{ }
I know how to make it work, that's not my concern.
I can just either:
GetFoo()
to IBar
, orGetBar
from the IFoo.GetBar()
methodWhat I am really asking is the reasoning for not just allowing the code above to compile. Is there any case where the above doesn't fulfill the contract specified by IFoo
.
Usually, I'd say that it would be a case of balancing the benefit against the added complexity of supporting such a feature. (All features take effort to design, document, implement, test, and then developers need to be educated about them too.) Note that there could be some significant complexities if you wanted to support returning a value type which implemented an interface, for example (as that ends up in a different representation, rather than just a reference).
In this case, I don't believe the CLR even supports such a feature, which would make it very hard for C# to do so cleanly.
I agree it would be a useful feature, but I suspect it hasn't been deemed useful enough to warrant the extra work required.