Why does C#/CLR not support method override co/contra-variance?

前端 未结 5 493
死守一世寂寞
死守一世寂寞 2020-12-02 01:48

There are quite a few questions & answers about hacking around the limitation of C# not allowing method return (and argument) types to be changed to compatible types on

5条回答
  •  鱼传尺愫
    2020-12-02 02:15

    Eric Lippert already answered this way better than I could.

    Check out his series on Covariance and Contravariance in C#

    and

    How does C# 4.0 Generic Covariance & Contra-variance Implmeneted?

    EDIT: Eric pointed out that he doesn't talk about return type convariance but I decided to keep the link in this answer because it is a cool series of articles and someone might find it useful if looking up this topic.

    This feature has been requested and almost 5 years ago Microsoft has responded with "Thanks for logging this. We hear this request a lot. We'll consider it for the next release."

    And now I'll quote Jon Skeet because it would not be a proper answer on StackOverflow without an answer by Jon Skeet. Covariance and void return types

    I strongly suspect that the answer lies in the implementation of the CLR rather than in any deep semantic reason - the CLR probably needs to know whether or not there's going to be a return value, in order to do appropriate things with the stack. Even so, it seems a bit of a pity, in terms of elegance. I can't say I've ever felt the need for this in real life, and it would be reasonably easy to fake (for up to four parameters) in .NET 3.5 just by writing a converter from Func to Action, Func to Action etc. It niggles a bit though :)

提交回复
热议问题