委托作为扩展方法的第一个参数
女士和男士，
我最近尝试过这个实验：
static class TryParseExtensions { public delegate bool TryParseMethod(string s, out T maybeValue); public static T? OrNull(this TryParseMethod 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("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.TryParse, "3"); var result4 = ((TryParseExtensions.TryParseMethod)int.TryParse).OrNull("4"); 我想知道两件事：
-
为什么编译器不能推断出“int”类型参数？
-
我是否正确理解在委托类型上没有发现扩展方法，因为我猜他们不是真的那种类型（但是“方法”）只碰巧匹配委托签名？ 因此，演员解决了这个问题。 启用方案1是否不可行（当然不是特定的，但总的来说）？ 我想从语言/编译器的角度来看它实际上是否有用，或者我只是（试图）在这里疯狂地滥用东西？
期待一些见解。 日Thnx
你在这里有很多问题。 （将来我会建议，当你有多个问题时，将它们分成多个问题，而不是一个问题，其中有几个问题;你可能会得到更好的答案。）
为什么编译器不能推断出“int”类型参数：
TryParseExtensions.OrNull(int.TryParse, "2");
好问题。 我没有在这里回答这个问题，而是向您推荐2007年的文章，该文章解释了为什么这在C＃3.0中不起作用：
总结：从根本上说，这里存在鸡与蛋的问题。 我们必须对int.TryParse执行重载解析以确定TryParse的哪个重载是预期的（或者，如果它们都不起作用，那么错误是什么。）重载决策总是试图从参数推断。 但在这种情况下，正是我们试图推断出的论证类型。
我们可以提出一种新的重载分辨率算法，该算法说“好吧，如果方法组中只有一种方法，那么即使我们不知道参数是什么，也要选择那种方法”，但这似乎很弱。 对于只有一个方法的特殊情况方法组来说，这似乎是一个坏主意，因为这会因为添加新的重载而惩罚你; 它可以突然变成一个突破性的变化。
从文章的评论中可以看出，我们得到了很多很好的反馈。 获得的最佳反馈基本上是“好的，假设类型推断已经解决了所有参数的类型，它是我们试图推断的返回类型 ;在这种情况下，你可以做超载解析”。 那个分析是正确的，并且这个效果的变化进入了C＃4。我在这里谈了更多：
我是否正确理解在委托类型上没有发现扩展方法，因为我猜他们不是真的那种类型（但是“方法”）恰好匹配代理签名？
你的术语有点偏，但你的想法是正确的。 当“接收器”是方法组时，我们不会发现扩展方法。 更一般地说，当接收器缺少自己的类型时，我们不会发现扩展方法，而是根据其上下文采用类型：方法组，lambdas，匿名方法和null文本都具有此属性。 说null.Whatever()并且调用String上的扩展方法，甚至更奇怪， (x=>x+1).Whatever()并在Func上调用扩展方法，这将是非常奇怪的Func 。
描述此行为的规范行是：
从[接收器表达式]到第一个参数[…]的类型的隐式标识，引用或装箱转换[必须存在]。
方法组的转换不是身份，参考或装箱转换; 它们是方法组转换。
启用方案1是否不可行（当然不是特定的，但总的来说）？ 我想从语言/编译器的角度来看它实际上是否有用，或者我只是（试图）在这里疯狂地滥用东西？
这不是不可行的 。 我们这里有一个非常聪明的团队，没有理论上的理由说明为什么不可能这样做。 我们似乎并不认为这种function可以为语言增加更多的价值而不是额外的复杂性。
有时它会有用。 例如，我希望能够做到这一点; 假设我有一个static Func ：
var fib = (n=>n<2?1:fib(n-1)+fib(n-2)).Memoize();
而不是今天你要写的，这是：
Func fib = null; fib = n=>n<2?1:fib(n-1)+fib(n-2); fib = fib.Memoize();
但坦率地说，所提出的function增加了语言的额外复杂性并没有因为使上面的代码更加冗长而获得的小优势。
第一个错误的原因：
int.TryParse是一个方法组，而不是任何类型的对象实例。 扩展方法只能在对象实例上调用。 这与以下代码无效的原因相同：
var s = int.TryParse;
这也是在第二个示例中无法推断类型的原因： int.TryParse是一个方法组，而不是TryParseMethod类型。
我建议你使用方法三并缩短扩展类的名称。 我认为没有更好的方法可以做到这一点。
请注意，如果您首次声明代码，则代码有效：
TryParseExtensions.TryParseMethod tryParser = int.TryParse;
然后使用tryParser ，你使用int.TryParse 。
问题是编译器不知道你正在谈论的int.Parse重载。 所以它不能完全推断它：你是在谈论TryParse(String, Int32)还是TryParse(String, NumberStyles, IFormatProvider, Int32) ？ 编译器无法猜测，也不会随意为您决定（幸运的是！）。
但是你的委托类型清楚地说明了你感兴趣的过载。这就是为什么分配tryParser不是问题。 你不再说“方法组”，而是在这组名为int.TryParse的方法中找到一个很好识别的方法签名。