编译器无法解析为预期的扩展方法

Question

我今天注意到在尝试将内联 lambda 函数转换为闭包时，我可以在多个地方使用相同的 lambda。这将编译为正确的扩展方法：

appBuilder.Use((ctx, next) => {
    Console.WriteLine("Test");
    return next();
});

Use 是由以下定义的扩展：

public static IAppBuilder Use(this IAppBuilder app, Func<IOwinContext, Func<Task>, Task> handler);

现在如果我做同样的事情，但将内联移动到一个变量：

Func<IOwinContext, Func<Task>, Task> handler = (ctx, next) => {
        Console.WriteLine("Test");
        return next();
    };
appBuilder.Use(handler);

编译器解析到这个方法（不是扩展）：

IAppBuilder Use(object middleware, params object[] args);

我在这里做什么来导致该方法更改签名？

提前致谢。

Answer 1

我在这里做什么来导致该方法更改签名？

lambda 表达式没有类型，只能转换为兼容的委托和表达式树类型。

因此，带有(object, params object[]) 参数的常规IAppBuilder 方法不适用于带有lambda 表达式参数的调用。此时，编译器将寻找扩展方法。

将其与带有handler 变量的版本进行比较——此时，您有一个 可转换为object 的参数，并且参数数组没有值...所以常规方法是适用的。

重要的是，如果编译器找到任何适用的非扩展方法，它会使用这些方法执行重载决议。 仅在没有非扩展方法适用时使用扩展方法。

如果您有两个扩展方法或两个常规方法，重载决议将确定具有更具体参数的那个比(object, params object[]) 更适合此调用...但事实并非如此；两者从来没有比较过。

Answer 2

Lambda 在 C# 中非常不寻常，因为它们是非常 几种实际上没有类型的表达式之一。他们依靠他们的上下文来知道他们的类型是什么。 （另一个例子是null。）

您可以采用完全相同的 lambda，并更改围绕它的代码，它会更改 lambda 解析为的类型。如果你把它放在某个期待Expression<T> 的地方，它会解析为一个表达式，如果你把它放在某个期待一个代表的地方，它最终会成为一个代表（两者完全不同），并且它绑定的委托类型基于预期的委托类型，因此同一个 lambda 可以根据预期解析为完全不同类型的委托。

几乎没有其他类似的行为；大多数表达式只有一种它们解析为的类型，您无需查看上下文即可确定该类型。

所以在你的第一个例子中，当你有：

(ctx, next) => {
    Console.WriteLine("Test");
    return next();
}

您无法单独确定类型。您需要查看该表达式的使用位置，以尝试找到 lambda 可以转换为的内容。该 lambda 无法转换为 object。编译器不知道它应该是一个表达式还是一个委托，或者它应该是 which 委托。但它可以将其转换为Func<IOwinContext, Func<Task>, Task>，因为它是适当类型的委托。这就是使用的重载。

当您传入handler 时，它不是一个lambda，它只是一个委托的实例，并且像任何其他对象 一样，可以转换为object，所以另一个重载是有效的，并且作为一个实例方法，当两者都有效时它“获胜”。

Answer 3

如果可能，实例方法（非扩展方法）获胜。

对于内联版本，它无法匹配，因为 lambda 本身没有类型；它不知道要创建什么委托类型，因此不能将其转换为object。因此，唯一可用的匹配是采用 Func<IOwinContext, Func<Task>, Task> 的扩展方法，因为 lambda 可以 强制转换为具体匹配的委托类型。

一旦你给 lambda 赋值一个局部变量：你已经给了它一个类型 - 一个可转换为对象的类型。所以现在实例方法是一个可行的候选方法，并且：获胜。

Answer 4

其他答案解释了为什么您的代码会如此行事。

这是解决原始问题的一种方法，能够重用 lambda：将其转换为本地函数：

Task Middleware(IOwinContextcontext, Func<Task> next)
{
    Console.WriteLine("test");
    return next();
}

app.Use(Middleware);