泛型是.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#的类型推断功能太强而降低了代码的可读性（因此有时候我们甚至于会“主动”加上类型），而不会在某个“是人都能看出来类型”的情况下，编译器缺如瞎了一般非要我们提供具体类型。