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: http://lab.msdn.microsoft.com/ProductFeedback/ViewFeedback.aspx?FeedbackID=FDBK16960


Comments (18)

  1. Jim Geurts says:

    out of curiousity, how many votes are required to make this a reality?

  2. Jim: The more the merrier :)

  3. Sam says:

    I never missed them, so why should I vote for them?

    Maybe I’m missing whats so helpful about them?

    Sam

  4. Jens Samson says:

    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.

  5. Jens, could you explain what you mean? The vote is for covariant return types in C# and .net.

  6. Sam, a useful example is:

    //represents an arbitrary node in an abstract syntax tree

    class AstNode

    {

    ….public virtual AstNode Parent { get { … } }

    }

    class NamespaceNode : AstNode

    {

    ….//Since i know that the parent of a namespace node is always a namespace node

    ….//i can declare it here. It’s totally fine since it follows the contract of the

    ….//supertype which states that you have to return an AstNode (and a

    ….//NamespaceNode is an AstNode

    ….public override NamespaceNode Parent { get { … } }

    }

    //but i can’t do that, i’m forced to do:

    class NamespaceNode : AstNode

    {

    ….public override ***AstNode*** Parent { get { … } }

    }

    Having covariant return types is useful for two reasons.

    First, when i’m implementing NamespaceNode.Parent, having the return type checked by the compiler is incredibly useful. It means that i can’t make a mistake where i accidently return a node that isn’t a NamespaceNode. Also, i have to document the property to state this so that anyone reading this will know.

    if in the future i ever need to change what .Parent returns there is no way to make sure that all the callers will still work correctly.

    Second, when someone is consuming these apis they now need to introduce casts all over the place.

    For example:

    NamespaceNode n = …

    NamespaceNode nParent = (NamespaceNode)n.Parent;

    this is error prone and cluttered. There is no need for that cast and it’s possible that it could cause a runtime exception.

    This can all be avoided with covariant return types. It allows for better defined APIs and easier consumption by users. It’s very much Win/Win.

  7. Jens Samson says:

    I’m sorry, I didn’t read it good enough. It indeed says ‘C# / all.NET languages’.

    I guess I’m still pissed about the refactoring decision and I’m venting that in the wrong place …

    Anyway, I did vote for it, and I do hope that if it gets included in the next .NET (whenever that will be) it’s not a C# only feature ‘because VB.NET developers are not really interested in this’.

  8. 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.

  9. Jens Samson says:

    Cyrus,

    It’s not that I think that C# gets more attention than VB.NET, it’s that sometimes I feel that the kind of attention VB.NET gets really affirmes the feeling that C# is the ‘business development’ language and VB.NET is the language that non-ITers use (business analysts, accountants, consultants, …).

    I guess my profile is much more the profile of a C# developer, except that I can’t stand curly braces, the cryptic way of writing code in C-derived languages, and case sensitivity. Some say that people like me should get over it and switch to C#, but that would take the joy out of developing, it would be an imense frustration to have to fight with the aforementioned reasons why I don’t like C# on a dialy basis. So I find myself a bit left out in the cold. The things C# gains are more geared towards professional developers (refactoring), the things VB.NET gains are more geared towards the others (My). Businesswise, this might be the correct decision for MS, one can only spend a dollar once, and throwing more developers at the problem is rarely the solution, but from my point of view the grass really *is* greener on the other side …

    If on the other hand things like Refactoring, E&C, CoVariant ReturnTypes are solved in the framework (or in Visual Studio, but then in common code), the grass is suddenly equally green on both sides and everyone is happy.

    Jens

  10. RonO says:

    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.

  11. AT says:

    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 😉

  12. RonO: How would you modify the overload lookup rules to account for return types?

  13. 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! :)

  14. Dmitry Shaporenkov says:

    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?

  15. 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.

  16. 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.

  17. RonO says:

    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. :)