Search

Need covariant return types in C# / all .Net langage by Olivier Higelin

Closed
as Postponed Help for as Postponed

297
3
Sign in
to vote
Type: Suggestion
ID: 90909
Opened: 10/22/2004 5:59:57 AM
Access Restriction: Public
Duplicates: 91798 92439 92749 93127
2
Workaround(s)
There is no covariant return type in C# !!!!
Details (expand)
Product Language
English
Version
Visual C# 2005 Express Beta 1
Category
Language/Compiler
Operating System
Windows XP Professional
Operating System Language
English
Proposed Solution
allow

public class AClass {}
public class BClass : AClass {}

public interface IBase
{
AClass GetStuff();
}
public interface IDerived : IBase
{
BClass GetStuff();
}

the covariance should be working on interface methode/property and class methode/property
Benefits
Faster Development
Improved Reliability
Improved Performance
Other Benefits
Faster Development
File Attachments
0 attachments
Sign in to post a comment.
Posted by kdhamane on 9/2/2011 at 5:09 AM
Eric Lippert has posted a comment on this:
http://stackoverflow.com/questions/4348760/c-covariant-return-types-utilizing-generics/4349584#4349584
In short, this will never make it into C# :(
Posted by Qwertie on 7/20/2011 at 3:07 PM
Come on MS, please reconsider! It seems like I'm routinely running into design problems where a covariant return value is the perfect solution. Get with the program! C++ has had this trivially simple feature for as long as I can remember.
Posted by Xlent_F on 9/14/2010 at 5:08 PM
Still no answers on this one! :( I registered just to add a request for this gap.
Posted by Tully Нillenbrand on 4/20/2010 at 5:31 PM
Adding another request for this. Maybe in .NET 5.0? Please Microsoft :'(
Posted by Cholent on 2/10/2010 at 1:07 PM
And will it be in C# and VB 4? Doesn't look like it! 5 years later!!!!!
Posted by Qwertie on 3/16/2009 at 3:38 PM
P.S. Covariant return types should include void -> anything

Base class: virtual void Foo()
Derived class: override string Foo()
Posted by Rüdiger Klaehn on 2/9/2009 at 1:58 PM
What is the point of the whole feedback mechanism? Obviously there are many people that think that this feature is very important. And it does not even require any CLR changes. Yet for more than four years nothing is done about this issue.

Instead we get this great new "dynamic" feature. Instead of writing x.Invoke("Bla",a,b), we can now write x.Bla(a,b). Yippee! That will enable an entirely new era of software development (NOT!)

Can somebody point me to the feedback item where 250 people voted the dynamic feature to be very important? No? I thought so. At least microsoft should be honest and just disable the feedback mechanism.
Posted by Anders Borum on 8/10/2008 at 12:18 PM
Yes, I've been pushing for covariant return types for a long type now and the replies we get from Eric Lippert (et all) doesn't really sound like they think it's an important feature. Which is really weird considering the massive number of requests for this feature.
Posted by Qwertie on 7/26/2008 at 3:12 PM
As of June 19, 2008, Eric Lippert stated on his blog: "we have no plans to implement [return type covariance] in C#."

Why the heck not? In terms of usefulness, it's in the same ballpark as variance in generics but a vastly simpler concept and easy to support in the CLR,
Posted by Qwertie on 4/12/2008 at 1:29 PM
"We hear this request a lot. We'll consider it for the next release." 3.5 years later, and still no updates on this issue :(
Posted by Microsoft on 10/29/2004 at 9:45 AM
Thanks for logging this. We hear this request a lot. We'll consider it for the next release.
Sign in to post a workaround.
Posted by Olivier Higelin on 1/6/2005 at 1:18 AM
When implementing interface methods you can achieve kind-of covariant return types by using explicit interface implementation

E.g.:
class MyCloneable : ICloneable {
    public MyCloneable Clone() {
        return new MyCloneable();
    }

    object ICloneable.Clone() {
        return Clone();
    }
}
Posted by Qwertie on 9/11/2008 at 11:40 PM
The above workaround is okay for implementing an interface, but what if you are writing a class hierarchy, and you want a Clone() method that is virtual?

class BaseNode : ICloneable
{
    object ICloneable.Clone() { return Clone(); }
    public virtual BaseNode Clone() { ... }
}
class ComplexNode : BaseNode
{
    override BaseNode BaseNode.Clone() { return Clone(); }
    public override ComplexNode Clone() { ... }
}

Oops, the workaround that you use for interfaces is illegal for class inheritance. There is still a solution, though:

class BaseNode : ICloneable
{
    object ICloneable.Clone() { return Clone(); }
    public BaseNode Clone() { BaseNode c; Clone(out c); return c; }
    protected virtual void Clone(out BaseNode clone) { ... }
}
class ComplexNode : BaseNode
{
    public new ComplexNode Clone() { ComplexNode c; Clone(out c); return c; }
    protected override void Clone(out BaseNode clone) { clone = Clone(); }
    protected virtual void Clone(out ComplexNode clone) { ... }
}

That's right. You need six Clone() methods. The last method is virtual in case you want to make a class derived from ComplexNode, e.g. VeryComplexNode:

class VeryComplexNode : BaseNode
{
    public new VeryComplexNode Clone() { VeryComplexNode c; Clone(out c); return c; }
    protected override void Clone(out BaseNode clone) { clone = Clone(); }
    protected override void Clone(out ComplexNode clone) { clone = Clone(); }
    protected void Clone(out VeryComplexNode clone) { ... }
}

Without covariant return types, you have to to define an additional virtual function for each additional derived class.