C# 中的三元数受到限制有什么充分的理由吗？

Question

失败：

object o = ((1==2) ? 1 : "test");

成功：

object o;
if (1 == 2)
{
    o = 1;
}
else
{
    o = "test";
}

第一个语句中的错误是：

无法确定条件表达式的类型，因为“int”和“string”之间没有隐式转换。

为什么需要这样，我将这些值分配给对象类型的变量。

编辑：上面的例子很简单，是的，但是有一些例子这会非常有帮助：

int? subscriptionID; // comes in as a parameter

EntityParameter p1 = new EntityParameter("SubscriptionID", DbType.Int32)
{
    Value = ((subscriptionID == null) ? DBNull.Value : subscriptionID),
}

Answer 1

使用：

object o = ((1==2) ? (object)1 : "test");

问题是条件运算符的返回类型无法明确确定。也就是说，int和string之间，没有最好的选择。编译器将始终使用 true 表达式的类型，并在必要时隐式转换 false 表达式。

编辑：
在第二个示例中：

int? subscriptionID; // comes in as a parameter

EntityParameter p1 = new EntityParameter("SubscriptionID", DbType.Int32)
{
    Value = subscriptionID.HasValue ? (object)subscriptionID : DBNull.Value,
}

PS：
这不称为“三元运算符”。它是一个三元运算符，但它被称为“条件运算符”。

Answer 2

尽管其他答案是正确，但就它们做出真实且相关的陈述而言，这里有一些语言设计的微妙点尚未表达。许多不同的因素影响了条件运算符的当前设计。

首先，希望尽可能多的表达式具有可以仅根据表达式的内容确定的明确类型。出于多种原因，这是可取的。例如：它使构建 IntelliSense 引擎变得更加容易。您输入 xM(some-expression. ，IntelliSense 需要能够分析 some-expression，确定其类型，并在 IntelliSense 知道 xM 引用的方法之前生成一个下拉列表IntelliSense 在看到所有参数之前无法确定 xM 所指的内容，但您甚至还没有输入第一个参数。

其次，我们更喜欢类型信息“从内到外”流动。正是我刚才提到的场景：重载解析。考虑以下内容：

void M(object x) {}
void M(int x) {}
void M(string x) {}
...
M(b ? 1 : "hello");

它应该做什么？它应该有时调用字符串重载，有时调用 int 重载吗？ code>M(IComparable x) -- 什么时候选择它？

当类型信息“双向流动”时，事情会变得非常复杂，因此编译器将这个东西分配给类型对象的变量。应该知道选择对象是可以的，因为类型”不会被洗掉；通常情况下，我们不知道要分配给的变量的类型，因为这就是我们正在处理的过程试图弄清楚。重载解析正是根据参数的类型计算出参数类型的过程，参数是要为其分配参数的变量。如果参数的类型取决于它们被分配的类型，那么我们的推理就会出现循环。

对于 lambda 表达式，类型信息确实“双向流动”；有效地实现这一点花了我一年的大部分时间。我写了一系列文章，描述了设计和实现编译器时遇到的一些困难，该编译器可以根据可能使用表达式的上下文来分析类型信息流入复杂表达式的情况；第一部分在这里：

http://blogs.msdn.com/ericlippert/archive/2007/01/10/lambda-expressions-vs-anonymous-methods-part-one.aspx

您可能会说“好吧，我明白为什么编译器不能安全地使用我分配给对象的事实，并且我明白为什么表达式必须具有明确的类型，但为什么不是表达式对象的类型，因为 int 和字符串可以转换为对象吗？”这引出了我的第三点：

第三，C# 微妙但一贯应用的设计原则之一是“不要用魔法产生类型”。当给定一个我们必须从中确定类型的表达式列表时，我们确定的类型总是在列表中的某个位置。我们从不创造出一种新类型并为您选择；您得到的类型始终是您给我们选择的类型。如果你说要在一组类型中找到最佳类型，我们会在该组类型中找到最佳类型。在集合 {int, string} 中，不存在最佳常见类型，例如“动物、海龟、哺乳动物、小袋鼠”。此设计决策适用于条件运算符、类型推断统一场景、隐式类型数组类型的推断等等。

这种设计决策的原因是，它使普通人更容易弄清楚编译器在必须确定最佳类型的任何给定情况下将要做什么；如果你知道某个类型就在那里，盯着你的脸，将会被选择，那么就更容易弄清楚将会发生什么。

它还避免了我们在存在冲突时必须制定大量复杂的规则来确定一组类型中最好的通用类型。假设您有类型 {Foo, Bar}，其中两个类都实现了 IBlah，并且两个类都继承自 Baz。哪个是最好的通用类型，IBlah（两者都实现）或 Baz（两者都扩展）？我们不想回答这个问题；我们想完全避免它。

最后，我注意到，在某些模糊的情况下，C# 编译器实际上对类型的确定存在微妙的错误。我关于此的第一篇文章在这里：

http://blogs.msdn.com/ericlippert/archive/2006/05/24/type-in​​ference-woes-part-one.aspx

事实上编译器做得正确并且规范是有争议的错误的;我认为实现设计比规范设计更好。

无论如何，这只是三元运算符这一特定方面的设计的几个原因。这里还有其他微妙之处，例如，CLR 验证程序如何确定给定的一组分支路径是否保证在所有可能路径中的堆栈上留下正确的类型。详细讨论这个问题会让我离题很远。

Answer 3

为什么功能 X 会这样通常是一个很难回答的问题。回答实际行为要容易得多。

我有根据的猜测为什么。条件运算符可以简洁地使用布尔表达式在 2 个相关值之间进行选择。它们必须是相关的，因为它们是在单个位置使用的。如果用户选择了 2 个不相关的值，则代码中可能存在细微的拼写错误/错误，编译器最好警告他们这一点，而不是隐式转换为对象。这或许是他们没有想到的。

Answer 4

“int”是原始类型，而不是对象，而“string”则被认为更多是“原始对象”。当您执行“object o = 1”之类的操作时，实际上是将“int”装箱为“Int32”。以下是有关拳击的文章的链接：

http://msdn.microsoft.com /en-us/magazine/cc301569.aspx

一般来说，应避免装箱，因为性能损失难以追踪。

当您使用三元表达式时，编译器根本不会查看赋值变量来确定最终类型是什么。将原始语句分解为编译器正在执行的操作：

语句：
对象 o = ((1==2) ? 1 : "测试");

编译器：

1. '((1==2) ? 1 : "test")' 中的“1”和“test”是什么类型？他们匹配吗？
2. #1 中的最终类型是否与“object o”的赋值运算符类型匹配？

由于编译器在 #1 完成之前不会评估 #2，因此它会失败。