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
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
Brannon B. King commented
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.
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.
This would be very useful feature in most factory pattern implementations.
Paulo Zemek commented
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)
if (source == null)
throw new ArgumentNullException("source");
var result = source.Clone();
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).