制作者：剑锋冷月 单位：无忧统计网,www.51stat.net
　　泛型是.NET平台上重要的功能，泛型即为一个“不确定”的类型。C# 3.0中加强了对于类型推断的力度。如果缺少了类型推断，那么C#中的大部分功能，如泛型方法的调用，Lambda表达式都会丧失大部分的可用性——因为过于复杂，所以没有人会去用（还记得这里的Java代码吗？）。
　　“类型推断”的功能便是希望编译器可以自动从上下文中“意识到”某个泛型参数的具体类型，而不用代码具体指明。但是有些时候我们会发现，C#的代码推断作的相当不完整。例如，我们准备了这样的代码：
public　interface　ISome　
{　
　　int　Method(string　arg);　
}　
　
public　class　Mock<T>　
{　
　　public　void　Setup<TResult>(Func<T,　TResult>　func)　{　}　
}　
　
public　static　class　It　
{　
　　public　static　T　IsAny<T>()　{　return　default(T);　}　
}　
　　熟悉Moq框架的朋友一定发现，这段代码和Moq的准备代码有些接近（当然，这里是委托，而Moq则用了表达式树）。于是我们往往希望写这样的代码：
var　mockSome　=　new　Mock<ISome>();　
mockSome.Setup(s　=>　s.Method(It.IsAny()));　
　　由于ISome接口的Method方法签名已经完全确定了，因此编译器完全可以推断出Setup方法和IsAny方法的泛型参数如何。但是如果你这么做的话，C#编译器会给出这样的错误信息：
　　The type arguments for method 'It.IsAny<T>()' cannot be inferred from the usage. Try specifying the type arguments explicitly.
　　它要求指定It.IsAny方法的泛型参数。事实上，光指定这个也不够，它继续要求Setup方法的泛型参数。因此，我们必须这么写：
var　mockSome　=　new　Mock<ISome>();　
mockSome.Setup<int>(s　=>　s.Method(It.IsAny<string>()));　
mockSome.Setup(s　=>　s.Method(It.IsAny<string>()));　
　　现在是int或string可能还没有太多问题，但如果您遇到了IGrouping<string, SortedDictionary<int, DateTime>>这种强大有力的类型，估计您会和我一样欲哭无泪。相信您也遇到过这样的问题。
　　本以为在大多数情况下不会遇见这样的问题（事实上平时的确用的挺爽），不过我刚才却不小心撞见了另一个古怪的情况，它耗费了我十几分钟的时间，最后在别人的提示下才发现问题所在。原因在于我写的通用扩展方法之一：
public　static　TDictionary　RemoveKeys<TDictionary,　TKey,　TValue>(　
　　this　TDictionary　source,　IEnumerable<TKey>　keys)　
　　where　TDictionary　:　IDictionary<TKey,　TValue>　
{　
　　foreach　(var　key　in　keys)　
　　{　
　　　　source.Remove(key);　
　　}　
　
　　return　source;　
}　
　　这个扩展方法的作用是从一个IDictionary对象中移除部分key对应的内容，内容本身很简单，但是使用时却出现了问题：
var　values　=　new　RouteValueDictionary();　
values.RemoveKeys(...);　
　　RouteValueDictionary是一个实现了IDictionary<string, object>接口的字典对象，因此应该一切正常吧，但是编译器却告诉我出了问题：
　　'System.Web.Routing.RouteValueDictionary' does not contain a definition for 'RemoveKeys' and no extension method 'RemoveKeys' accepting a first argument of type 'System.Web.Routing.RouteValueDictionary' could be found.
　　这个错误提示和之前的不同，它告诉我们缺少RemoveKeys方法，而并没有要求我们补全泛型参数。但是一旦补全了泛型参数就没有问题了：
values.RemoveKeys<RouteValueDictionary,　string,　object>(...);
　　但是您会愿意写这样的代码吗？
　　因此，最后我不得不补充了另一个方法，误打误撞地绕开了“强制指定泛型参数”的方法：
public　static　IDictionary<TKey,　TValue>　RemoveKeys<TKey,　TValue>(　
　　this　IDictionary<TKey,　TValue>　source,　IEnumerable<TKey>　keys)　
{　
　　foreach　(var　key　in　keys)　
　　{　
　　　　source.Remove(key);　
　　}　
　
　　return　source;　
}　
　　这个方法直接使用了IDictionary<TKey, TValue>类型，而不是把它作为泛型参数的限制条件——问题就这么解决了。别问我为什么，我也不知道……
　　虽然从表面上解决了这个问题，但是它带来的限制也是很明显的：虽然新的方法也可以作用在字典类型上，但是新方法只能返回IDictionary<TKey, TValue>类型，旧的方法返回的则是原有的类型（如RouteValueDictionary）。返回原有的类型就可以利用其Fluent Interface，让代码编写更为方便。
　　这个应该算是C#编译器的bug吧，不知道有没有其他朋友遇到过。C#编译器半吊子的类型推断特性，总是能够不断给我们“惊喜”。还是一些函数式语言的类型推断最为强大，如Haskell或F#。在编写代码的时候，只会由于F#的类型推断功能太强而降低了代码的可读性（因此有时候我们甚至于会“主动”加上类型），而不会在某个“是人都能看出来类型”的情况下，编译器缺如瞎了一般非要我们提供具体类型。
　　出处：http://www.cnblogs.com/JeffreyZhao/archive/2009/08/20/type-inference-bug-in-csharp.html
　　它要求指定It.IsAny方法的泛型参数。事实上，光指定这个也不够，它继续要求Setup方法的泛型参数。因此，我们必须这么写：
var　mockSome　=　new　Mock<ISome>();　
mockSome.Setup<int>(s　=>　s.Method(It.IsAny<string>()));　
mockSome.Setup(s　=>　s.Method(It.IsAny<string>()));　
　　现在是int或string可能还没有太多问题，但如果您遇到了IGrouping<string, SortedDictionary<int, DateTime>>这种强大有力的类型，估计您会和我一样欲哭无泪。相信您也遇到过这样的问题。
　　本以为在大多数情况下不会遇见这样的问题（事实上平时的确用的挺爽），不过我刚才却不小心撞见了另一个古怪的情况，它耗费了我十几分钟的时间，最后在别人的提示下才发现问题所在。原因在于我写的通用扩展方法之一：
public　static　TDictionary　RemoveKeys<TDictionary,　TKey,　TValue>(　
　　this　TDictionary　source,　IEnumerable<TKey>　keys)　
　　where　TDictionary　:　IDictionary<TKey,　TValue>　
{　
　　foreach　(var　key　in　keys)　
　　{　
　　　　source.Remove(key);　
　　}　
　
　　return　source;　
}　
　　这个扩展方法的作用是从一个IDictionary对象中移除部分key对应的内容，内容本身很简单，但是使用时却出现了问题：
var　values　=　new　RouteValueDictionary();　
values.RemoveKeys(...);　
　　RouteValueDictionary是一个实现了IDictionary<string, object>接口的字典对象，因此应该一切正常吧，但是编译器却告诉我出了问题：