generics：为什么在这种情况下编译器不能推断出类型参数？我想编写一个扩展方法，该方法适用于值按某种顺序排列的字典。不幸的是，编译器似乎无法从我对该方法的使用中推断出泛型参数；我需要明确指定它们。publicstaticvoidSomeMethod(thisIDictionarydict)whereTValue:IEnumerable{}staticvoidUsage(){vardict=newDictionary();vardict2=newDictionary();//这些不编译dict.SomeMethod();一些方法（字典）；//与扩展方法没有任何关系dict2.SomeMethod();//希望这会更容易推断但没有乐趣//这些工作正常dict.SomeMethod();dict2.SomeMethod();我意识到类型推断不是一门精确的科学，但我想知道我是否在这里遗漏了一些基本的“规则”——我不熟悉规范的细节。这是推理过程的缺点，还是我期望编译器在这种情况下“弄清楚”是不合理的（也许是模棱两可的）？我可以更改方法的签名，使其功能相同但“可推断”吗？我意识到类型推断不是一门精确的科学，我不确定我是否同意。规范非常详细。我想知道这里是否有一些您遗漏的基本“规则”可能是约束不是签名的一部分。类型推断取决于签名。在我看来，这个设计决定有充分的理由。然而，很多人认为我认为有充分的理由做出道德上错误的设计决定。如果您有兴趣阅读关于我是对还是错这个主题的几百万字，这里是我关于这个主题的文章和一百多条评论告诉我我错了：http://blogs.msdn.com/b/ericlippert/archive/2009/12/10/constraints-are-not-part-of-the-signature.aspx这是推理过程的缺点吗？可以，是的。在我看来，这是基于竞争设计要求的合理选择。（那些“成为用户意味着什么”和“当事情看起来模棱两可时给出错误”。）在这种情况下期望编译器应该“弄清楚”是不合理的吗？不，你看起来像一个通情达理的人，你的期望似乎是基于很好的推理。但是，完全有可能有一个合理的期望未得到满足。这将是其中一个案例。我可以更改方法的签名，使其功能相同但“可推断”吗？这很难，因为泛型Dictionary类型在其转换中既不是协变的也不是逆变的。您想要捕获的概念不容易以提供推理的方式在类型系统中表达。如果您更喜欢具有更高级类型推断的语言，请考虑F#。如果您更喜欢一种倾向于“成为用户意味着什么”而不是“报告模糊错误”的语言，请考虑使用VB。C#类型推断不受约束或返回值的影响。所以你很幸运publicstaticvoidSomeMethod(thisIDictionary>dict){}如果你将param声明为newDictionary>()，这将起作用，但如果你将它声明为newDictionary>()则不起作用。我不得不说，按照我阅读c#规范第7.5.2节的方式，似乎自List实现IEnumerable以来，TUnderlyingValue的类型推断应该起作用。但是，那部分不是很容易理解。我不认为它可以通过多个“层”工作，因为SomeMethod(IEnumberableval){}用SomeMethod(newList())SomeMethod(newList())可以很好地调用它。我在规范中没有看到任何专门针对解析U=Ca>的类型的内容，因此可能未定义推理级别。为什么不省略IEnumerable的类型？以上是C#学习教程：Generics:Whycan'tthecompilerinferthetypeparametersinthiscase?分享的所有内容，如果对你有用，需要了解更多C#学习教程，希望你多多关注——publicstaticvoidSomeMethod(thisIDictionarydict)whereTValue:IEnumerable{}这篇文章是收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
