命名参数和C＃4.0泛型类型推理 [英] Named arguments and generic type inference in C# 4.0
问题描述
我一直假设下的编程，在打电话时的方法C＃4.0，提供为你的论点名称将不会影响结果，除非这样做你被跳过一个或多个可选参数。
I had been programming under the assumption that, when calling a method in C# 4.0, supplying names for your arguments would not affect the outcome unless in doing so you were "skipping" one or more optional parameters.
所以我有点惊讶地发现以下行为：
So I was a bit surprised to discover the following behavior:
由于这需要一个 Func键℃的方法; T> ，执行它并返回结果：
Given a method which takes a Func<T>, executes it and returns the result:
public static T F<T>(Func<T> f)
{
return f();
}
和另一种方法从上述方法是可见的：
And another method from which the above method is visible:
static void Main()
{
string s;
调用F（不带命名参数）编译没有任何问题：
calling F (without named arguments) compiles without any issues:
s = F<string>(() => "hello world"); // with explicit type argument <string>
s = F(() => "hello world"); // with type inference
和使用命名参数时...
And when using a named argument...
s = F<string>(f: () => "hello world");
...使用明确的类型参数上面的代码行仍然编译没有问题。也许不是太奇怪，如果你有ReSharper的安装会提示类型的参数规格是多余的。
... the above line of code using the explicit type argument still compiles without issues. And maybe not too surprisingly, if you have ReSharper installed it will suggest that the "Type argument specification is redundant".
不过，删除类型参数的时候...
However, when removing the type argument...
s = F(f: () => "hello world");
C＃编译器会报告这个错误：
the C# compiler will report this error:
有关方法'Program.F（System.Func）'的类型参数不能从使用推断。尝试显式指定类型参数。
The type arguments for method 'Program.F(System.Func)' cannot be inferred from the usage. Try specifying the type arguments explicitly.
有没有命名参数和类型推断之间的这种相互作用合乎逻辑的解释？
Is there a logical explanation for this interaction between named arguments and type inference?
这是行为语言规范的地方记录？
Is this behavior documented somewhere in the language specification?
据我所知，这是没有必要的，我的名字的说法。然而，我发现了一个更复杂的场景，我想这可能是有意义的命名参数在我的方法调用内部文档目的此行为。我不问如何解决这个问题。 。我想了解一些语言的细微之处的
I understand that it is not necessary at all for me to name the argument. However, I discovered this behavior in a much more complex scenario where I thought it might make sense to name the arguments in my method call for internal documentation purposes. I am not asking how to work around this issue. I am trying to understand some of the finer points of the language.
为了让事情更有趣，我发现没有问题之后的所有编译：
To make things more interesting I discovered that the following all compiles without issues:
Func<string> func = () => "hello world";
s = F<string>(func);
s = F(func);
s = F<string>(f: func);
s = F(f: func);
}
通过我的观察与非静态方法相同的行为方式。我只是选择了用静态的方法，使这里的例子有点短。
By the way I have observed the same behavior with non-static methods. I just chose to use static methods to make the example here a bit shorter.
推荐答案
推理是不是将在许多工作嵌套水平的汇编。它是一种基于供应参数的猜测。我觉得编译器编写者没有考虑使用命名参数一起推断的逻辑。如果考虑抽象语法树，即使逻辑是一样的，但都
F（（）=>XYZ）
和
F（F：（）=>XYZ ）
是从编译器的角度来看，不同的抽象语法树。
Inference is not something that will work at many nested levels in compilation. It is kind of a guess based on arguments supplied. I feel the compiler writers did not consider inferring logic along with named parameter. If you consider abstract syntax tree, Even though the logic is same, but both F(()=>"xyz") And F(f:()=>"xyz") Are different abstract syntax trees from compiler's perspective.
我觉得它只是由编译器设计师，甚至编译器本身是一个拥有巨大的一套规则程序错过了规则。一个规则匹配第一个案例，但没有规则匹配第二个。这可能是概念上的权利，但编译器只是一个程序和所有的规则都是人类编码。
I feel it's just a rule missed by compiler designer where even the compiler itself is a program with huge set of rules. One rule matches first case but no rule matches second one. It may be conceptually right but compiler is just a program and all rules are human coded.
好吧，我猜正如其他人决定的，它的错误，应该报告给Microsoft！
Ok, I guess as others have determined, its a bug and should be reported to Microsoft !!
这篇关于命名参数和C＃4.0泛型类型推理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
