Covariant Return Types

One of the discussions on one of the CLI mailing lists (on the server), I raised the idea of adding
Covariant Return Types to the CLS.
At the moment, the only responder, Jonathan Pryor from the Mono team,
has answered me with some very interesting points.
For those of you who are not in that list, here is the transcript.

Here are a few quotes from the list:

Covariant Return Types support means that you will be able to write the following code:

public class ClassA { }
public class ClassB : ClassA { }
public class MyClass
public virtual ClassA DoSomething()
// Work magic...
// Return an instance of type ClassA.
public class MyDerivedClass : MyClass
public override ClassB DoSomething()
// Work magic...
// Return an instance of type ClassB.

This would mean that I could use a derived type as the return type for overriding methods.
This check could be very easy, since method signatures do not vary on the basis of their return type.
The greatest advantage this embodies is the ability to type the return value for specific implementations of derived

A great addition to this (I’m not sure if this is included in the definition) could be this:

public class MyClass : System.Object, System.IClonable
public MyClass Clone()
// Return a copy of the current object.

This would mean that return types for implemented methods could be altered in the same fashion.

– Omer van Kloeten

To which the reply was:


They could be useful. However, to be truly useful they’d need to be part of the Common Language Specification (CLS).
Additionally, covariant return types still wouldn’t be needed, as the method overloading technique used by C# is
virtually required for decent use of the class libraries. Consider: System.Collections.IEnumerable and
System.Collections.IDictionary both provide the GetEnumerator() method, but with different return types. Also note that
IDictionary implements the IEnumerable interface.

Thus, if a language wants to allow developers to implement the standard IDictionary interface, the language *must*
permit explicit method implementation (permitting separate implementations of the IEnumerable.GetEnumerator() and
IDictionary.GetEnumerator() methods).

– Jonathan Pryor

My Reply:


You are correct, the language would have to permit explicit interface implementation to use both interfaces.
However, let’s look at your example from another perspective: Why does the IDictionary interface declare this

The IDictionary.GetEnumerator() method is only there because there are no Covariant Return Types, meaning the
interface can not implicitly convert the return type of the inherited method, thus requiring it to create a new
definition with the needed return type.
This is one of the types of confusion Covariant Return Types come to prevent.

– Omer van Kloeten

He Replied:


To return to the original question, should covariant return types be supported by the runtime, I still believe that
the answer is “no”. Explicit method implementation is a sufficient replacement, at least at the IL level.

Individual languages can support covariant return types, with the compiler for those languages using the explicit
method implementation approach when generating code, and looking for similar method overloading patterns when consuming
existing code. This permits maximum flexibility — languages without support for covariant return types can still get
similar benefits with explicit methods, and users of languages supporting covariant return types reap the benefits of
less typing. :-)

– Jonathan Pryor

I snipped some parts that I think were not really important. If I have removed something of significance, please let me
Well, this is still being talked about. Feel free to comment here or join in if you have some good input on the


2 thoughts on “Covariant Return Types

  1. ;o) Simplicity vs. power of use ?

    Do you have any limitation currently that prevent you from doing your job ?

    BTW, Will this new addition increare/decrease code readability ?? IMHO, Readability will decrease. You will be unable to understand the following line:

    a = b.getFoo();

    Do you wish every line users check that type of "a" and that methods "b" implement ?

  2. As I stated, this is not a required feature, but a useful addon.

    Covariant Return Types mean that if you wish to change the return type on an overriden method, it would have to derive from the original return type, as you can see in my first example.
    I hope this answers your question.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s