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

chr*_*aut 9 c# extension-methods delegates

女士和男士们,

我最近尝试过这个实验:

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");
Run Code Online (Sandbox Code Playgroud)

我想知道两件事:

  • 为什么编译器不能推断出"int"类型参数?

  • 我是否正确理解在Delegate类型上没有发现扩展方法,因为我猜他们不是真的那种类型(但是"方法")只碰巧与代理签名相匹配?因此,演员解决了这个问题.启用方案1是否不可行(当然不是特定的,但总的来说)?我想从语言/编译器的角度来看它实际上是否有用,或者我只是(试图)在这里疯狂地滥用这些东西?

期待一些见解.日Thnx

Eri*_*ert 19

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

为什么编译器不能推断出"int"类型参数:

TryParseExtensions.OrNull(int.TryParse, "2");  
Run Code Online (Sandbox Code Playgroud)

好问题.我没有在这里回答这个问题,而是向您介绍我2007年的文章,该文章解释了为什么这在C#3.0中不起作用:

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

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

我们可以提出一种新的重载解析算法,该算法说"好吧,如果方法组中只有一种方法,那么即使我们不知道参数是什么,也要选择那种方法",但这似乎很弱.对于只有一个方法的特殊情况方法组来说,这似乎是一个坏主意,因为这样会因为添加新的重载而惩罚你; 它可以突然变成一个突破性的变化.

正如您从该文章的评论中看到的那样,我们得到了很多很好的反馈.获得的最佳反馈基本上是"好的,假设类型推断已经解决了所有参数的类型,它是我们试图推断的返回类型 ;在这种情况下,你可以做超载解析".那个分析是正确的,并且这个效果的变化进入了C#4.我在这里谈到了更多:

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

我是否正确理解,在委托类型上没有发现扩展方法,因为我猜他们不是真的那种类型(但是"方法")恰好匹配代理签名?

你的术语有点偏,但你的想法是正确的.当"接收器"是方法组时,我们不会发现扩展方法.更一般地,我们没有发现扩展方法时,接收器是什么,缺乏它自己的类型,而是需要基于上下文类型:方法组,lambda表达式,匿名方法和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();
Run Code Online (Sandbox Code Playgroud)

而不是你今天要写的,这是:

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

但坦率地说,所提出的功能增加了语言的额外复杂性并不是通过使上面的代码更简洁的小优点来支付的.