C# Futures: Covariant Return Types

A frequent API design problem is the inability to use a more specific return type when overriding a method. A good example of this is your typical Clone method.

public abstract Request Clone();

In a subclass, you may wish to implement it like this:

public override FtpRequest Clone() { ... }

Since FtpRequest is a subclass of Request, logically this makes sense. But you actually do it in .NET because overrides have to be an exact match. Nor can you have an override and a new method that only differ by the return type. So usually you end up with something complex such as:

public Request Clone() => OnClone();
protected abstract Request OnClone();

Then in the subclass:

public new FtpRequest Clone() => (FtpRequest)OnClone();
protected override Request OnClone() { ... }

The ability to change the return type of an overridden method is being explored in Proposal 49, Covariant Return Types .

When originally proposed in 2017, this feature would have been implemented using some “compiler magic”. As of October of 2019, the focus has changed towards making this a first-class feature of the CLR.

In the Covariant Return Types - Draft Specification , the IL directive .override will be changed to,

The override method must have a return type that is convertible by an identity or implicit reference conversion to the return type of the overridden base method.

Currently the rule is,

The override method and the overridden base method have the same return type.

Properties and Indexers

Properties and indexers are included in this feature, but only if they are read-only. There will not be matching support for contravariant property and index setters.

Interfaces

Methods on interfaces can override covariant methods on base interfaces using the same rules as sub-classes/base classes.

When a class implements an interface, the implementing method can be covariant with the interface method.

For purposes of interface mapping, a class member A matches an interface member B when:

A and B are methods, and the name and formal parameter lists of A and B are identical, and the return type of A is convertible to the return type of B via an identity of implicit reference conversion to the return type of B .

This rule change for implicitly implemented interfaces could result in a breaking change. This would happen in the unusual situation where a subclass re-implements an interface already implemented by the base class.

interface I1 { object M(); }
class C1 : I1 { public object M() { return "C1.M"; } }
class C2 : C1, I1 { public new string M() { return "C2.M"; } }

Andy Gocke proposed a slight modification to the rule to avoid the breaking change,

Could we change the search for mapping members to consider implicit implementations with different covariant returns iff there is no other implementation (including a default one)?

Unfortunately, this is not compatible with default implementations on interfaces. Neal Gafter writes,

I don’t see how that would work in binary compatibility scenarios. If a new version of the interface is released with a default implementation then the runtime would change to use that one instead of the implementation from the base class?

Prioritization of the necessary runtime support for covariant return types is being tracked internally at Microsoft.