35

编译这个简单的程序：

class Program
{
    static void Foo( Action bar )
    {
        bar();
    }

    static void Main( string[] args )
    {
        Foo( () => Console.WriteLine( "42" ) );
    }
}

那里没有什么奇怪的。如果我们在 lambda 函数体中出错：

Foo( () => Console.LineWrite( "42" ) );

编译器返回错误消息：

error CS0117: 'System.Console' does not contain a definition for 'LineWrite'

到现在为止还挺好。现在，让我们在调用中使用命名参数Foo：

Foo( bar: () => Console.LineWrite( "42" ) );

这一次，编译器消息有些混乱：

error CS1502: The best overloaded method match for 
              'CA.Program.Foo(System.Action)' has some invalid arguments 
error CS1503: Argument 1: cannot convert from 'lambda expression' to 'System.Action'

这是怎么回事？为什么它不报告实际错误？

请注意，如果我们使用匿名方法而不是 lambda，我们确实会收到正确的错误消息：

Foo( bar: delegate { Console.LineWrite( "42" ); } );
4

3 回答 3

36

为什么它不报告实际错误？

不，这就是问题所在；它正在报告实际错误。

让我用一个稍微复杂一点的例子来解释一下。假设你有这个：

class CustomerCollection
{
    public IEnumerable<R> Select<R>(Func<Customer, R> projection) {...}
}
....
customers.Select( (Customer c)=>c.FristNmae );

好的，根据 C# 规范，错误是什么？您必须在这里非常仔细地阅读规范。让我们解决它。

  • 我们调用 Select 作为一个函数调用，只有一个参数，没有类型参数。我们在 CustomerCollection 中的 Select 上进行查找，搜索名为 Select 的可调用事物——即诸如委托类型的字段或方法之类的事物。由于我们没有指定类型参数，我们匹配任何泛型方法 Select。我们找到一个并从中构建一个方法组。方法组包含单个元素。

  • 现在必须通过重载解析来分析方法组，首先确定候选集，然后从中确定适用的候选集，并从中确定最佳适用候选，并从中确定最终验证的最佳适用候选。如果这些操作中的任何一个失败，则重载解析必须失败并出现错误。其中哪一个失败了？

  • 我们从构建候选集开始。为了获得候选者，我们必须执行方法类型推断以确定类型参数 R 的值。方法类型推断如何工作？

  • 我们有一个 lambda，它的参数类型都是已知的——形式参数是 Customer。为了确定 R，我们必须将 lambda 的返回类型映射到 R。lambda 的返回类型是什么？

  • 我们假设 c 是 Customer 并尝试分析 lambda 主体。这样做会在 Customer 的上下文中查找 FristNmae，但查找失败。

  • 因此，lambda 返回类型推断失败，并且没有向 R 添加边界。

  • 在分析完所有参数之后，R 没有界限。因此，方法类型推断无法确定 R 的类型。

  • 因此方法类型推断失败。

  • 因此没有方法被添加到候选集中。

  • 因此，候选集为空。

  • 因此，不可能有适用的候选人。

  • 因此，此处正确的错误消息应该是“重载解决方案无法找到最终验证的最佳适用候选，因为候选集为空”。

客户会对该错误消息非常不满。我们在错误报告算法中构建了相当多的启发式算法，试图推断出用户实际上可以采取行动来修复错误的更“基本”错误。我们推理：

  • 实际的错误是候选集是空的。为什么候选集为空？

  • 因为方法组中只有一种方法，类型推断失败。

OK，是不是应该报错“overload resolution failed because method type inference failed”？同样，客户会对此不满意。相反，我们再次问这个问题“为什么方法类型推断失败？”

  • 因为 R 的有界集是空的。

这也是一个糟糕的错误。为什么边界设置为空？

  • 因为我们可以确定 R 的唯一参数是无法推断其返回类型的 lambda。

OK，是不是应该报错“overload resolution failed because lambda return type inference failed to infer a return type”？ 同样，客户会对此不满意。相反，我们会问“为什么 lambda 无法推断出返回类型？”

  • 因为客户没有名为 FristNmae 的成员。

这就是我们实际报告的错误。

所以你看到了我们必须经过的绝对曲折的推理链才能给出你想要的错误信息。我们不能只说出了什么问题——重载决策被赋予了一个空的候选集——我们必须追溯过去以确定重载决策是如何进入那个状态的。

这样做的代码非常复杂；它处理的情况比我刚才介绍的更复杂，包括有 n 个不同的泛型方法并且类型推断由于 m 个不同的原因而失败的情况，我们必须从所有这些情况中找出什么是给出的“最佳”理由用户。回想一下，实际上有十几种不同类型的 Select 和重载解决方案可能因不同的原因或相同的原因而失败。

编译器的错误报告中有用于处理各种重载解析失败的启发式；我描述的只是其中之一。

所以现在让我们看看你的具体情况。真正的错误是什么？

  • 我们有一个方法组，其中有一个方法，Foo。我们可以建立一个候选集吗？

  • 是的。有一个候选人。方法 Foo 是调用的候选方法，因为它提供了所有必需的参数 -- bar -- 并且没有额外的参数。

  • 好的，候选集中只有一个方法。候选集中有适用的成员吗？

  • 不能。 bar 对应的实参无法转换为形参类型，因为 lambda 主体包含错误。

  • 因此适用候选集是空的，因此没有最终验证的最佳适用候选，因此重载决策失败。

那么错误应该是什么？同样，我们不能只说“重载解决方案未能找到最终验证的最佳适用候选人”，因为客户会讨厌我们。我们必须开始挖掘错误信息。为什么重载解析失败？

  • 因为适用的候选集是空的。

为什么是空的？

  • 因为里面的每个候选人都被拒绝了。

有没有可能的最佳人选？

  • 是的，只有一名候选人。

为什么被拒绝了？

  • 因为它的参数不能转换为形式参数类型。

好的，在这一点上，显然处理涉及命名参数的重载解决问题的启发式方法决定我们已经挖掘得足够远，这是我们应该报告的错误。如果我们没有命名参数，那么其他一些启发式方法会问：

为什么论点不可转换？

  • 因为 lambda 主体包含错误。

然后我们报告该错误。

错误启发式方法并不完美；离得很远。巧合的是，我本周正在对“简单”重载解决错误报告启发式进行重架构——就像什么时候说“没有采用 2 个参数的方法”和什么时候说“你想要的方法是私有的” " 以及何时说“没有与该名称对应的参数”，等等；完全有可能您正在调用带有两个参数的方法，没有该名称的具有两个参数的公共方法，有一个是私有的，但其中一个具有不匹配的命名参数。快，我们应该报告什么错误？我们必须做出最好的猜测，有时我们可以做出更好的猜测，但还不够复杂。

即使做到这一点也被证明是一项非常棘手的工作。当我们最终重新构建大型重型启发式方法时——比如如何处理 LINQ 表达式中方法类型推断的失败——我将重新审视您的案例，看看我们是否可以改进启发式方法。

但是由于您收到的错误消息是完全正确的，这不是编译器中的错误；相反，它只是特定情况下错误报告启发式的缺点。

于 2011-11-08T20:26:51.637 回答
6

编辑：Eric Lippert 的回答描述了（好多了）这个问题——请看他对“真正的交易”的回答

最终编辑：对于一个人来说，在野外公开展示自己的无知是令人不快的，但在按下删除按钮后掩盖无知并没有任何好处。希望其他人可以从我的不切实际的回答中受益:)

感谢 Eric Lippert 和 svick 耐心地纠正我有缺陷的理解！

您在此处收到“错误”错误消息的原因是由于类型的差异和编译器推断以及编译器如何处理命名参数的类型解析

主要例子的类型 () => Console.LineWrite( "42" )

通过类型推断和协变的魔力，这与最终结果相同

Foo( bar: delegate { Console.LineWrite( "42" ); } );

第一个块可以是 typeLambdaExpression或delegate; 这取决于使用和推理。

鉴于此，难怪编译器在传递一个应该是 anAction但可能是不同类型的协变对象的参数时会感到困惑？错误消息是指向类型解析是问题的主要关键。

让我们看一下 IL 以获取更多线索：给出的所有示例都在 LINQPad 中编译为此：

IL_0000:  ldsfld      UserQuery.CS$<>9__CachedAnonymousMethodDelegate1
IL_0005:  brtrue.s    IL_0018
IL_0007:  ldnull      
IL_0008:  ldftn       UserQuery.<Main>b__0
IL_000E:  newobj      System.Action..ctor
IL_0013:  stsfld      UserQuery.CS$<>9__CachedAnonymousMethodDelegate1
IL_0018:  ldsfld      UserQuery.CS$<>9__CachedAnonymousMethodDelegate1
IL_001D:  call        UserQuery.Foo

Foo:
IL_0000:  ldarg.0     
**IL_0001:  callvirt    System.Action.Invoke**
IL_0006:  ret         

<Main>b__0:
IL_0000:  ldstr       "42"
IL_0005:  call        System.Console.WriteLine
IL_000A:  ret

请注意调用System.Action.Invoke:周围的 **callvirt正是它看起来的样子：一个虚拟方法调用。

当您Foo使用命名参数调用时，您是在告诉编译器您正在传递一个Action，而您真正传递的是一个LambdaExpression. 通常，这会被编译（注意在CachedAnonymousMethodDelegate1ctor for 之后调用的IL中Action的！ActionLambdaExpressionAction

简短：命名参数解析失败，因为 lambda 表达式中的错误（这本身就是一个硬故障）

这是另一个告诉：

Action b = () => Console.LineWrite("42");
Foo(bar: b);

产生预期的错误消息。

我可能对某些 IL 内容不是 100% 准确，但我希望我传达了大致的想法

编辑： dlev 在 OP 的评论中提出了一个很好的观点，即重载解决的顺序也发挥了作用。

于 2011-11-08T16:50:20.273 回答
4

注意：不是真正的答案，但对于评论来说太大了。

当你投入类型推断时会得到更有趣的结果。考虑这段代码：

public class Test
{
    public static void Blah<T>(Action<T> blah)
    {
    }

    public static void Main()
    {
        Blah(x => { Console.LineWrite(x); });
    }
}

它不会编译，因为没有很好的方法来推断T应该是什么。
错误信息：

'Test.Blah<T>(System.Action<T>)'无法从用法中推断出方法的类型参数。尝试明确指定类型参数。

说得通。让我们明确指定类型，x看看会发生什么：

public static void Main()
{
    Blah((int x) => { Console.LineWrite(x); });
}

现在事情出了差错，因为LineWrite不存在。
错误信息：

“System.Console”不包含“LineWrite”的定义

也很理智。现在让我们添加命名参数，看看会发生什么。首先，不指定类型x：

public static void Main()
{
    Blah(blah: x => { Console.LineWrite(x); });
}

我们希望收到关于无法推断类型参数的错误消息。我们做到了。但这还不是全部。
错误信息：

'Test.Blah<T>(System.Action<T>)'无法从用法中推断出方法的类型参数。尝试明确指定类型参数。

“System.Console”不包含“LineWrite”的定义

整洁的。类型推断失败，我们被告知 lambda 转换失败的确切原因。好的，让我们指定类型x并看看我们得到了什么：

public static void Main()
{
    Blah(blah: (int x) => { Console.LineWrite(x); });
}

错误信息：

'Test.Blah<T>(System.Action<T>)'无法从用法中推断出方法的类型参数。尝试明确指定类型参数。

“System.Console”不包含“LineWrite”的定义

现在这是出乎意料的。类型推断仍然失败（我假设是因为 lambda ->转换失败，因此否定了编译器Action<T>的猜测T）并报告了失败的原因。int

TL; DR：当 Eric Lippert 开始研究这些更复杂案例的启发式方法时，我会很高兴。

于 2011-11-08T21:04:20.667 回答