4

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));
    }
}
Ani
  • 111,048
  • 26
  • 262
  • 307
mtraudt
  • 103
  • 4

2 Answers2

8

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>

Community
  • 1
  • 1
Ani
  • 111,048
  • 26
  • 262
  • 307
  • 1
    Thanks, this is the reference that I was looking for. And your guess as to why there is an inconsistency makes sense to me as well. – mtraudt Sep 03 '12 at 23:03
2

D1 excepts an argument of type Tiger but you're passing in a type of Animal. Animal is not a Tiger But Tiger is an Animal

robert.oh.
  • 644
  • 2
  • 5
  • 13
  • Animal is less specific, so assigning a function that takes an `Animal` to a delegate that's specifying a `Tiger` shouldn't be a problem. `M1` is less specific than `D1`. – BAF Sep 01 '12 at 15:17
  • +1. Yeah. Co- and contravariance are often mind boggling and do not work the way that you would intuitively think of in the first time. – Olivier Jacot-Descombes Sep 01 '12 at 15:22
  • How does your answer not apply to the method-group conversion `D1 func = M1;`? – Ani Sep 01 '12 at 16:04
  • 2
    Ani is correct. This answer does not take into account the fact that the statement `D1 func = M1;` works as expected. – mtraudt Sep 03 '12 at 23:02