c# - 作为第一个参数委托(delegate)给扩展方法

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”类型的参数？

• 我是否正确理解扩展方法不会在委托(delegate)类型上被发现，因为我猜它们不是真正的那种类型(而是一种“方法”)，只是恰好与委托(delegate)签名相匹配？这样的类型转换解决了这个问题。启用场景 1 是否可行(当然不是具体的，但一般来说)？我想从语言/编译器的角度来看它是否真的有用，或者我只是(试图)疯狂地滥用这里的东西？

期待一些见解。谢谢

Answer 1

您在这里有很多问题。 (将来我会建议当你有多个问题时，将它们分成多个问题，而不是一个帖子中包含多个问题；你可能会得到更好的答复。)

Why can the compiler not infer the "int" type parameter in:

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

Do I understand correctly that extensions methods do not get discovered on delegate types, as I guess they arent really of that type (but are a "Method") that only happen to match the delegates signature?

你的术语有点不对，但你的想法是正确的。当“接收者”是一个方法组时，我们不会发现扩展方法。更一般地说，当接收者是缺少自己类型的东西时，我们不会发现扩展方法，而是根据其上下文采用一种类型:方法组、lambda、匿名方法和 null 文字都具有此属性。说null.Whatever()真的很奇怪并在 String 上调用扩展方法，甚至更奇怪，(x=>x+1).Whatever()并在 Func<int, int> 上调用扩展方法.

描述此行为的规范行是:

An implicit identity, reference or boxing conversion [must exist] from [the receiver expression] to the type of the first parameter [...].

方法组上的转换不是标识、引用或装箱转换；它们是方法组转换。

Would it be infeasable to enable scenario 1 to work (not this one specifically of course, but in general)? I guess from a language/compiler perspective and would it actually be useful, or am I just (attempting to) wildly abusing things here?

这不是不可行。我们这里有一个非常聪明的团队，没有理论上不可能这样做的理由。在我们看来，与额外的复杂性成本相比，它似乎不喜欢为语言增加更多值(value)的功能。

有时候它会很有用。例如，我希望能够做到这一点；假设我有一个 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();

但坦率地说，所提议的功能给语言增加的额外复杂性并不能通过使上述代码不那么冗长这一小小的好处来弥补。