C＃委托逆变与lambda表达式 [英] C# delegate contravariance with lambda expression

问题描述

第二个测试方法，下面不编译（不能转换lambda表达式到目标类型 D1 ）。这是否意味着（非通用）委托逆变不lambda表达式的工作？

  [的TestFixture] 
公类MyVarianceTests 
 {
私人抽象类动物{} 
私有类虎：动物{} 
 
私人委托类型D1（虎）; 
 
私有静态类型M1（兽兽）
 {
返回animal.GetType（）; 
} 
 
 [测试] 
公共无效ContravariantDelegateWithMethod（）
 {
 D1 FUNC = M1; 
型结果= FUNC（新虎（））; 
 Assert.AreEqual（结果的typeof（虎））; 
} 
 
 [测试] 
公共无效ContravariantDelegateWithLambda（）
 {
 D1 FUNC =（兽兽）=> animal.GetType（）; 
型结果= FUNC（新虎（））; 
 Assert.AreEqual（结果的typeof（虎））; 
} 
} 
  

解决方案

您'已经确定了语言的不一致性。

这是在的语言规范：

7.15。 1匿名函数签名

[...]相反，方法组转换（6.6节），匿名函数
参数的禁忌方差不支持的类型。 [...]

...这提出了一个问题：

为什么没有语言设计者费心支持此功能

<炒作>

显然，该功能有一些小的好处。但它证明了兼容的编译器实现所需的额外并发症的费用？

当你写一个lambda表达式，你必须的已的认识到底哪个代表/表达式树键入它正在转换（有没有通用的类型，可以抱任意拉姆达）。由于C＃5，一个lambda（与方法）提供其他完全没有目的的，而不是在创作的单的委托/表达式树实例的帮助。因此，有没有优势（除了方便外）的明确的指定比所需的参数，并期望从编译器禁忌方差支持更广泛的类型。你可以只完全省略的类型和依靠类型推断（或者最坏的情况，明确指定所需的确切参数类型），而可重用性或表达性的任何损失。

这显然不适用的方法，这比服务创造的代表/表达式树等其他用途。你可能希望有一个特定的函数签名（从委托的不同），因为它是最合适的，或者的需要的，因为它必须满足一个接口的合同。更进一步，认为您（作为程序员创建委托/表达式树）并不一定是自己有问题的方法（它可以在一个第三方组件）当您正在执行的方法组转换。这是从来没有与lambda表达式的情况。

它出现在语言设计者认为实施参数类型的lambda表达式禁忌方差没有理由成本的好处，不像对于法团

< /投机>

The second test method below does not compile (cannot convert lambda expression to target type D1). Does that mean that (non-generic) delegate contravariance does not work with lambda expressions?

[TestFixture]
public class MyVarianceTests
{
    private abstract class Animal {}
    private class Tiger : Animal {}

    private delegate Type D1(Tiger tiger);

    private static Type M1(Animal animal)
    {
        return animal.GetType();
    }

    [Test]
    public void ContravariantDelegateWithMethod()
    {
        D1 func = M1;
        Type result = func(new Tiger());
        Assert.AreEqual(result, typeof (Tiger));
    }

    [Test]
    public void ContravariantDelegateWithLambda()
    {
        D1 func = (Animal animal) => animal.GetType();
        Type result = func(new Tiger());
        Assert.AreEqual(result, typeof (Tiger));
    }
}

解决方案

You've identified an inconsistency in the language.

This is called out explicitly in the language specification:

7.15.1 Anonymous function signatures

[...] In contrast to method group conversions (§6.6), contra-variance of anonymous function parameter types is not supported. [...]

...which raises the question:

Why didn't the language designers bother supporting this feature?

<speculation>

Clearly, the feature has some small benefits. But does it justify the costs of the extra complications required in a compliant compiler implementation?

When you write a lambda expression, you must already know exactly which delegate/expression-tree type it is being converted to (there's no general-purpose type that can "hold" an arbitrary lambda). As of C# 5, a lambda (in contrast to a method) serves absolutely no purpose other than to help in the creation of a single delegate / expression-tree instance. Consequently, there's no advantage (other than convenience) to explicitly specifying a more general type than required for a parameter and expecting contra-variance support from the compiler. You could just omit the type completely and rely on type-inference (or, worst case, explicitly specify the exact parameter-type required) without any loss in reusability or expressibility.

This obviously doesn't apply to methods, which serve other purposes other than the creation of delegates/expression-trees. You may desire a particular function signature (different from the delegate's) because it is the most appropriate, or require it because it must satisfy an interface contract. Further more, consider that you (as the programmer creating the delegate/expression-tree) don't necessarily "own" the method in question (it could be in a third-party assembly) when you are performing a method-group conversion. This is never the case with lambdas.

It appears the language-designers felt the benefits of implementing contra-variance of parameter types for lambdas didn't justify the costs, unlike for method-groups.

</speculation>

这篇关于C＃委托逆变与lambda表达式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！