I suggest you ...

Support covariant return types

Allow covariant return types in the CLR for overrides and interface implementations. I frequently think of designs where this would be useful, and the workarounds can be pretty clumsy: http://loyc-etc.blogspot.com/2008/09/simulating-covariant-return-types-in-c.html

This suggestion is also listed on MS connect; I'm not sure why MS has two web sites for suggestions. http://connect.microsoft.com/VisualStudio/feedback/details/90909/need-covariant-return-types-in-c-all-net-langage

82 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Qwertie shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for taking the time to share this suggestion. This item has been around for a couple of versions of Visual Studio and we haven’t acted on it. Looking at the VS “15” plans, we’re not going to take action on this item, so we’re going to close it. If the suggestion is still relevant, please either take a look to see if there’s another suggestion that’s similar that you can vote on, or open a new suggestion.

- The Visual Studio Team


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Brannon B. King commented  ·   ·  Flag as inappropriate

    Adding a little more here so this shows up better in the search: Allow overridden methods to return an inheritor of the base class return value. The same goes on "out" parameters.

  • Fred commented  ·   ·  Flag as inappropriate

    People ask about return type covariance literally multiple times every single day on StackOverflow. Eric Lippert has said the C# guys are opposed to doing the feature, but you should really reconsider. There is clearly a large need for this feature.

  • lost commented  ·   ·  Flag as inappropriate

    This would be very useful feature in most factory pattern implementations.

  • Paulo Zemek commented  ·   ·  Flag as inappropriate

    I tried to vote but I am out of votes.
    Actually my workaround is the use of extension methods.
    For example: TypedClone (as we can't use existing methods).
    I create something like:
    public static void T TypedClone<T>(this T source)
    T: ICloneable
    if (source == null)
    throw new ArgumentNullException("source");

    var result = source.Clone();
    return (T)result;

    The biggest drawback is that if you forget a using clause, the method is not available. I am not sure right now, but I think extension methods appears for private interface implementations... if they don't, then that's another problem (as we will always see the Clone and the TypedClone).

Feedback and Knowledge Base