代码改变世界

C#编译器对泛型方法调用作类型推断的奇怪问题

2009-08-20 16:50 Jeffrey Zhao 阅读(...) 评论(...) 编辑 收藏

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