Tsk tsk!

Only 70 votes so far for covariant return types in C# (and all .Net languages)!! :-(

I thought that there was a lot more interest than that.

Here's a chance for you to really show what you're interested in seeing.  If you haven't voted yet, and you do care about this, do it asap:

If you go to this page you can submit your vote: https://lab.msdn.microsoft.com/ProductFeedback/ViewFeedback.aspx?FeedbackID=FDBK16960

Comments

• Anonymous
  March 21, 2005
  out of curiousity, how many votes are required to make this a reality?
• Anonymous
  March 21, 2005
  Jim: The more the merrier :)
• Anonymous
  March 21, 2005
  I never missed them, so why should I vote for them?
  
  Maybe I'm missing whats so helpful about them?
  
  Sam
• Anonymous
  March 21, 2005
  Maybe it might help if you were asking for votes for CoVariant Return Types in the whole of .NET, so that afte the dust settles this is not again a feature that is C#-only. The E&C for C#, no Refactoring for VB.NET failure was more then enough.
• Anonymous
  March 21, 2005
  Jens, could you explain what you mean? The vote is for covariant return types in C# and .net.
• Anonymous
  March 21, 2005
  The comment has been removed
• Anonymous
  March 21, 2005
  The comment has been removed
• Anonymous
  March 21, 2005
  Jens: NP
  
  I can understand your frustration though. but you should not think that C# gets more attention than VB because it's absolutely not the case.
  
  Rather each team tries to figure out hte best they can do with the time they have. So C# did things like refactoring, and VB did things like "My".
  
  I wouldn't mind talking about this a little more with you though cuz i really want you to know how we decide on all of this stuff.
• Anonymous
  March 21, 2005
  The comment has been removed
• Anonymous
  March 21, 2005
  I voted.
  
  Peripherially, are you also going to push for overloads that only differ in return type? I don't see it on your list of requests for the next version of C# (though this would probably be something baked into the CLS). Sadly, I don't have a ready example of where I'd've like to use it, but I do recall wanting the feature several times over the past couple years.
• Anonymous
  March 22, 2005
  Anybody who still has spare votes - can cast them once more at about the same suggestion at http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=FDBK12437
  
  This suggestion is "Under Review" since 2004-07-22 ;-)
• Anonymous
  March 22, 2005
  RonO: How would you modify the overload lookup rules to account for return types?
• Anonymous
  March 22, 2005
  Jens: Thanks for the thoughtful feedback. I've sent your feedback to the VB team which is very understanding of these issues. If you're interested with communication with someone from that team, send me your email address (through the contact link on the left) and i'll get you connected with them.
  
  I think they woudl like to talk in depth about how you feel and what they can do to rectofy the situation.
  
  Note: If it makes you feel better C# still doesn't have background compile, and there are many C# users who think the grass is greener on the VB side because of that! :)
• Anonymous
  March 22, 2005
  Voted. BTW, I've noticed that the request has Postponed/Closed status. Does it really mean that we have no chance to get covariant return types in Whibey or am I missing something?
• Anonymous
  March 22, 2005
  Dmitry: The chance of covariant return types being in whidbey is practically Nill. However, when planning the features for the next release this info will go a long way.
• Anonymous
  March 22, 2005
  Dmitry: The chance of covariant return types being in whidbey is practically Nill. However, when planning the features for the next release this info will go a long way.
• Anonymous
  March 22, 2005
  Cyrus: Re overload lookup rules, as I see it (admittedly I very well could be missing a lot of details in the overall picture), this is only a problem when there could be ambiguity in determining the return type. An arbitrary example (thanks to C-Sharp Corner for the base of the code):
  
  class CombineUtil
  {
  static double Combine(object a,object b)
  {
  return (double)a+(double)b;
  }
  static string Combine(object a,object b)
  {
  return Convert.ToString(a)+ " " + Convert.ToString(b);
  }
  
  public static void Main()
  {
  Console.WriteLine("Concat double: {0}", Combine(1.2,1.8));
  Console.WriteLine("Concat string: {0}", Combine("1.2","1.8"));
  Console.Read();
  }
  
  I'd raise a compile error to require the code to explictly cast to a valid return type (or one that can be unabiguously determined). The same checks are currently performed for method params (or at least the same types of checks), so I expect it could be adapted (if not used directly) to make the same determinations.
  
  Of course, I realize this is my own pie-in-the-sky dreaming on this issue. :)