BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News C# Futures: Covariant Return Types

C# Futures: Covariant Return Types

Bookmarks

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 can't actually do it in .NET because overrides has 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 if 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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • C# Futures: Covariant Return Types

    by Eirik Mangseth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    About bloody time.

  • Typo?

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Is the "new" supposed to be in this line?

    "public new string M()"

  • Re: Typo?

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, it is correct. The keyword `new` in this context means "I am intentionally hiding the base class method".


    I think the VB keyword `Shadows` more accurately describes what's happening. The original method still exists, it hasn't been overridden, but you can't access it unless you cast to the base class.

  • Re: Typo?

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Wow. Ok. Wow.

    Isn't "override" already a keyword? :D

  • Re: Typo?

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    But what if you forget to use `override`? Then it would accidentally hide the base method instead of replacing it, which is usually not what you want.

    C# forces you to choose `new` or `override` so it knows your intent.

  • Re: Typo?

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ah ... right. I had forgotten about the C# insane lack of virtual methods by default (what a crazy bad decision that was), and the corresponding need to have the "new" keyword in declarations to avoid warnings.

    I'm going to have nightmares tonight.

  • Re: Typo?

    by Ror Pop,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Virtual methods are more expensive to bind, so C# has a very good reason not to make them the default.

  • Re: Typo?

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "more expensive to bind"

    Yeah, you're spinning up a VM in a serverless environment for a few seconds to launch Windows to run a .NET process to parse an HTTP request containing an XML SOAP message with JSON parameters to do a CRUD request to a database and encode the response as text and send it across the Internet, and the one CPU instruction necessary to de-reference a v-table is your performance issue.

    Dude, the extra de-reference argument was already pretty bad in 1990 when Stroustrup was still making that argument for bad C++ design. It certainly wasn't a good argument for a language like C# 10 years later. And now, 20 years later? In 2020?

    Look at the assembly difference between a virtual and a non-virtual call.

    :-D

  • Re: Typo?

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Virtual calls cannot be inlined, which mean other interesting optimizations are prevented.

    This is why the CLR team has recently been spending so much effort on devirtulization techniques. (And why Java has already done so.)

  • Re: Typo?

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Virtual calls can be inlined. (Java has been doing just that FOR OVER 20 YEARS NOW!)

    I acknowledge that it is harder to inline virtual method calls, but you would think that a company like Microsoft could afford to hire someone with the necessary skills....

    Lastly, C# shouldn't be about "interesting optimizations". If we wanted optimizations, we'd use C++. C# is not C++, and every time people pretend that it could be, the language gets uglier and uglier. (Java suffers from the same tragic mistake. Some sort of envy.) Seriously, let C++ be ugly C++, and have higher level (aka not-crappy) languages focus on higher level stuff.

    What I'm trying to say: Worrying about optimizations with C# is honestly a bit laughable. If performance were actually important, then someone would have fixed the garbage collector years ago.

    Peace,

    Cameron.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT