Question

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));
    }
}

Answer 1

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>