Question

这只是一个好奇心，是否有一个基本的东西阻止这样的事情（或纠正我，如果已经有某种方式）：

public TTo Convert<TTo, TFrom>(TFrom from)
{
    ...
}

这样称呼：

SomeType someType = converter.Convert(someOtherType);

Answer 1

因为如果你这样做会发生什么？

static void M(int x){}
static void M(double x){}
static T N<T>() {}
...
M(N());

现在什么是T？ int还是double？

当您知道分配给的类型时，解决问题非常容易，但很多时候您指定的类型就是你的问题我试图弄清楚。

从内到外的推理很难。从外到内推理要困难得多，同时做两件事非常困难。如果编译器很难理解正在发生的事情，想象一下当人们在从进行推断时，尝试阅读，理解和调试代码的难度有多大。 em>和 to 表达式上下文的类型。这种推理使程序更难理解，而不是更容易，因此将它添加到C＃是一个坏主意。

现在，说，C＃支持lambda表达式的这个功能。当面对一个重载解决问题，其中lambda可以绑定两个，三个或一百万个不同的方式时，我们将它绑定两个，三个或一百万个不同的方式，然后评估那些百万种不同的可能绑定确定哪一个是“最好的”。这使得C＃中的重载分辨率至少达到NP-HARD，并且我花了一年多的时间来实现。我们愿意做出这样的投资，因为（1）lambdas很棒，（2）大多数时候人们编写的程序可以在合理的时间内进行分析，并且可以被人类理解。所以这是值得的。但总的来说，这种先进的分析不值得花费。

Answer 2

C＃表达式总是*具有固定类型，无论其周围环境如何。

你要的是一个表达式，其类型由分配给它的任何东西决定;那会违反这个原则。

*）除了lambda表达式，函数组和null文字。

Answer 3

与Java不同，在C＃类型中，引用不基于返回类型。并且不要问我为什么，Eric Lippert回答了这些“为什么不能C＃......”的问题：

因为没有人设计，指定，实施，测试，记录并发送该功能

C＃是否支持返回类型的类型推断？

3 个答案: