Question

女士和男士，

我最近尝试过这个实验：

static class TryParseExtensions
{
    public delegate bool TryParseMethod<T>(string s, out T maybeValue);
    public static T? OrNull<T>(this TryParseMethod<T> tryParser, string s) where T:struct 
    {
        T result;
        return tryParser(s, out result) ? (T?)result : null;
    }
}

// compiler error "'int.TryParse(string, out int)' is a 'method', which is not valid in the given context"
var result = int.TryParse.OrNull("1");  // int.TryParse.OrNull<int>("1"); doesnt work either

// compiler error: type cannot be infered....why?
var result2 = TryParseExtensions.OrNull(int.TryParse, "2"); 

// works as expected
var result3 = TryParseExtensions.OrNull<int>(int.TryParse, "3");
      var result4 = ((TryParseExtensions.TryParseMethod<int>)int.TryParse).OrNull("4");

我想知道两件事：

为什么编译器不能推断出“int”类型参数？
我是否正确理解在委托类型上没有发现扩展方法，因为我猜他们不是真的那种类型（但是“方法”）恰好匹配代理签名？因此，演员解决了这个问题。启用方案1是否不可行（当然不是特定的，但总的来说）？我想从语言/编译器的角度来看它实际上是否有用，或者我只是（试图）在这里疯狂地滥用这些东西？

期待一些见解。日Thnx

Answer 1

这里有很多问题。（将来我建议当你有多个问题时，将它们分成多个问题，而不是一个问题，其中包含几个问题;你可能会得到更好的答案。）

为什么编译器不能在：
中推断出“int”类型参数

TryParseExtensions.OrNull(int.TryParse, "2");

好问题。我没有在这里回答这个问题，而是向您推荐我的2007年文章，该文章解释了为什么这在C＃3.0中不起作用：

http://blogs.msdn.com/b/ericlippert/archive/2007/11/05/c-3-0-return-type-inference-does-not-work-on-member-groups.aspx

总结：从根本上说，这里存在鸡与蛋的问题。我们必须对int.TryParse执行重载解析，以确定TryParse的哪个重载是预期的（或者，如果它们都不起作用，那么错误是什么。）重载决策总是试图从参数推断。但在这种情况下，正是我们试图推断出的论证类型。

我们可以提出一种新的重载分辨率算法，该算法说“好吧，如果方法组中只有一个方法，那么即使我们不知道参数是什么，也选择那个方法”，但这似乎很弱。对于只有一个方法的特殊情况方法组来说，这似乎是一个坏主意，因为这会因为添加新的重载而惩罚你;它可能会突然发生变化。

从对该文章的评论中可以看出，我们得到了很多很好的反馈。获得的最佳反馈基本上是“好的，假设类型推断已经已经计算出所有参数的类型，并且它是我们试图推断的返回类型;在这种情况下，你可以做超载分辨率“。那个分析是正确的，并且这种效果的变化进入了C＃4。我在这里谈了更多：

http://blogs.msdn.com/b/ericlippert/archive/2008/05/28/method-type-inference-changes-part-zero.aspx

我是否正确理解在委托类型上没有发现扩展方法，因为我猜他们不是真的那种类型（但是“方法”）只碰巧与代理签名匹配？

你的术语有点偏，但你的想法是正确的。当“receiver”是方法组时，我们不会发现扩展方法。更一般地说，当接收器缺少自己的类型时，我们不会发现扩展方法，而是根据其上下文采用类型：方法组，lambdas，匿名方法和null文本都具有此属性。说null.Whatever()并将该调用称为String上的扩展方法，甚至是更奇怪的(x=>x+1).Whatever()并将该调用作为Func<int, int>上的扩展方法，这将是非常奇怪的。

描述此行为的规范行是：

从[接收器表达式]到第一个参数[...]的类型的隐式标识，引用或装箱转换[必须存在]。

方法组的转化不是身份转换，参考转换或拳击转换;它们是方法组转换。

启用方案1是否不可行（当然不是特定的，但总的来说）？我想从语言/编译器的角度来看它实际上是否有用，或者我只是（试图）在这里疯狂地滥用这些东西？

不是不可行。我们这里有一个非常聪明的团队，并且没有理论理由为什么不可能这样做。我们似乎并不认为这种功能可以为语言增加更多价值而不是额外复杂性的成本。

有时它会有用。例如，我希望能够做到这一点;假设我有static Func<A, R> Memoize<A, R>(this Func<A, R> f) {...}：

var fib = (n=>n<2?1:fib(n-1)+fib(n-2)).Memoize();

而不是今天你要写的东西，而不是：

Func<int, int> fib = null;
fib = n=>n<2?1:fib(n-1)+fib(n-2);
fib = fib.Memoize();

但坦率地说，所提出的功能增加了语言的额外复杂性并没有因为使上面的代码更加冗长而带来的微小好处。

Answer 2

第一次错误的原因：
int.TryParse是方法组，不是任何类型的对象实例。扩展方法只能在对象实例上调用。这与以下代码无效的原因相同：

var s = int.TryParse;

这也是在第二个示例中无法推断出类型的原因：int.TryParse是一个方法组，而不是TryParseMethod<int>类型。

我建议您使用方法三并缩短该扩展类的名称。我认为没有更好的方法可以做到。

Answer 3

请注意，如果您首次声明代码，则代码可以正常运行：

TryParseExtensions.TryParseMethod<int> tryParser = int.TryParse;

然后使用tryParser使用int.TryParse。

问题是编译器不知道你所说的int.Parse的哪个重载。所以它无法完全推断出来：您是在谈论TryParse(String, Int32)还是TryParse(String, NumberStyles, IFormatProvider, Int32)？编译器无法猜测，也不会随意为您决定（幸运的是！）。

但是你的委托类型清楚地说明了你感兴趣的重载。这就是为什么分配tryParser不是问题。你不再说“方法组”，而是在这组名为 int.TryParse 的方法中找到一个明确的方法签名。

委托作为扩展方法的第一个参数

3 个答案: