关于 C# 语言规范中隐式转换的问题

Question

第 6.1 节隐式转换定义了身份转换：

身份转换可以从任何类型转换为相同类型。这种转换的存在使得已经具有所需类型的实体可以说可以转换为该类型。

现在，这些句子的目的是什么？

（在第 §6.1.6 隐式引用转换中）

隐式引用转换是：

• [...]
• 从任何引用类型到引用类型 T（如果它具有到引用的隐式标识或引用转换） -type T₀ 和 T₀ 具有到 TT.

和：

（在 §6.1.7 拳击转换中）

• 如果值类型具有到接口类型 I 的装箱转换，则它具有到接口类型 I 的装箱转换，并且 < code>I₀ 具有到 I 的恒等转换。

最初它们看起来是多余的（同义反复）。但他们的存在一定是有目的的，那么他们为什么会存在呢？

您能否举出两种类型 T₁、T₂ 的示例，使得 T如果不是上述情况，₁将无法隐式转换为T₂ -引用的段落？

Answer 1

2010 年 9 月 22 日更新：

我怀疑除了 Timwi 之外还有人会读到这篇文章。即便如此，我还是想对这个答案进行一些编辑，因为新的答案现已被接受，并且关于规范引用的摘录是否正确的争论仍在继续（至少在我可能想象的世界中）在技​​术上是多余的。我没有添加太多内容，但内容太多，无法发表评论。大部分更新可以在下面的标题“涉及动态类型的转换”下找到。

---

2010 年 9 月 19 日更新：

在您的评论中：

[T]这没有道理。

该死的，Timwi，你说了很多次。但好吧，那么；你让我处于守势，所以开始吧！

免责声明：我绝对没有像您一样仔细地检查了该规范。根据您最近提出的一些问题，您似乎最近对此进行了相当多的研究。这自然会让你比 SO 上的大多数用户更熟悉很多细节；因此，就像您可能从埃里克·利珀特以外的任何人那里收到的大多数答案一样，这可能不会令您满意。

不同的前提

首先，您问题的前提是，如果突出显示的陈述是多余的 em>，那么它们就没有任何目的。我的回答的前提是，如果冗余陈述澄清了一些并非每个人都显而易见的内容，那么它们不一定是没有目的的。这些都是矛盾的前提。如果我们不能在前提上达成一致，我们就无法进行简单的逻辑论证。我只是要求你重新考虑你的前提。

然而，你的回应是重申你的前提：“如果这些句子确实是多余的，那么它们只会让读者感到困惑，而不会澄清任何事情。”

（顺便说一句，我喜欢你将自己设置为规范所有读者的代表。）

我不能责怪你担任这个职位。我的意思是，这确实看起来是显而易见的。而且我在原来的回答中没有给出任何具体的例子。所以下面我将尝试包括一些具体的例子。但首先，让我退后一步，谈谈为什么规范中首先存在这种奇怪的身份转换概念。

身份转换定义的目的

乍一看，这个定义似乎相当多余；事实上，这个定义似乎是多余的。这不是说任何类型 T 的实例都可以转换为……好吧，转换为 T 吗？是的。但我假设*该定义的目的是为规范提供适当的词汇，以便在讨论转换的背景下利用类型标识的概念。

这允许有关本质上具有传递性的转换的声明。您从规范中引用的第一点作为同义反复语句的示例就属于此类。它表示，如果为某种类型（我称之为 K）定义了到另一种类型 T₀ 的隐式转换，并且 T₀ 具有以下身份转换： T，那么 K 可以隐式转换为 T。根据上面给出的身份转换的定义，“具有身份转换”实际上意味着“与...是相同的类型”。所以这个语句是多余的。

但再说一次：身份转换定义的存在首先是为了给规范配备一种正式的语言来描述转换，而不必说“if T_{0”之类的东西} 和 T 确实是同一类型。”

好的，是时候看具体例子了。

对于某些开发人员来说，隐式转换的存在可能并不明显

注意：Eric Lippert 提供了一个更好示例他对问题的回答 。我留下前两个例子只是对我的观点的次要强化。我还添加了第三个示例，具体化了 object 和 dynamic 之间存在的身份转换，如 Eric 的答案中指出的。

传递引用转换

假设您有两种类型，M 和 N，并且您已经定义了如下隐式转换：

public static implicit operator M(N n);

然后您可以编写如下代码：

N n = new N();
M m = n;

现在假设您有一个文件上面有这个 using 语句：

using K = M;

然后在文件后面：

N n = new N();
K k = n;

好的，在我继续之前，我意识到这对你来说是显而易见的，并且 <强>我。但我的答案是，并且从一开始就是如此，这可能不是对每个人来说都是显而易见的，因此指定它——虽然多余——仍然有目的。

这个目的是：让任何摸不着头脑、查看该代码的人都明白，它是合法的。从N到M存在隐式转换，从M到K存在身份转换（即M和K是同一类型）；因此存在从 N 到 K 的隐式转换。这不仅仅是逻辑上的（尽管它可能是逻辑上的）； 它就在规范中。否则，人们可能会错误地认为类似以下内容是必要的：

K k = (M)n;

显然，事实并非如此。

传递装箱转换

或者采用int类型。 int 可以装箱为 IComparable，对吧？所以这是合法的：

int i = 10;
IComparable<int> x = i;

现在考虑一下：

int i = 10;
IComparable<System.Int32> x = i;

再次，是的，对于你、我以及 90% 可能遇到过它的开发人员来说，这可能是显而易见的。但对于极少数没有立即看到这一点的人来说：存在从 int 到 IComparable 的装箱转换，以及 < em>存在从 IComparable 到 IComparable 的身份转换（即 IComparable 和IComparable 是相同类型）；因此存在从 int 到 IComparable 的装箱转换。

涉及 dynamic 类型的转换

我将借用上面的引用转换示例，并稍微调整它以说明 object 和 dynamic 在规范的 4.0 版本中。

假设我们有类型 M 和 N，并且在某处定义了以下隐式转换：

public static implicit operator M<object>(N n);

那么以下是合法的：

N n = new N();
M<dynamic> m = n;

显然，上面的远不及 <比前面两个例子明显。但这是一个价值百万美元的问题：即使问题中引用的规范摘录不存在，上述仍然是否合法？（我将致电为了简洁起见，摘录了Q。）如果答案是肯定的，那么Q实际上是多余的。如果不是，那就不是。

我相信答案是肯定的。

考虑第 6.1.1 节中定义的身份转换的定义（我将整个部分放在这里，因为它很短）：

身份转换可以从任何类型转换为相同类型。这种转换的存在使得已经具有所需类型的实体可以说可以转换为该类型。

因为 object 和 dynamic 被认为是等价的，所以 object 和 dynamic 之间存在身份转换，以及用object替换所有出现的dynamic时相同的构造类型之间。 [强调我的]

（最后一部分也包含在第 4.7 节中，它定义了 dynamic 类型。）

现在让我们再次看一下代码。我特别对这一行感兴趣：

M<dynamic> m = n;

该声明的合法性（忽略Q - 请记住，正在讨论的问题是上述声明的假设合法性if Q不存在），因为 M 和 N 是自定义类型，取决于是否存在N 和 M 之间的用户定义隐式转换。

存在从 N 到 M

因此，就像前两个（更明显的）示例一样，我相信即使没有，也确实存在从 N 到 M 的隐式转换。考虑到Q，就像第一个示例中确实存在从N到K的隐式转换一样，并且在第二个示例中，存在从 int 到 IComparable 的装箱转换。

如果没有Q，这一点就不太明显（因此Q的存在）； 但这并不意味着它是错误的（即，Q 对于定义此行为来说不是必需的）。它只是让它变得不那么明显。

结论

我在最初的回答中说过，这是“显而易见的”解释，因为在我看来，你找错了对象。您最初提出了这个挑战：

您能否给出两种类型 T₁、T₂ 的示例，这样 T₁ 就不会隐式转换为 T₂如果不是上面引用的段落？

蒂姆维，没有人会迎接这个挑战，因为这是不可能的。摘录有关引用转换的第一个摘录。也就是说，如果类型 K 可以隐式转换为 T₀ 并且 T₀ 与 T 相同，则类型 K 可以隐式转换为类型 T。解构这个，将其放入回到一起，你会得到一个明显的同义反复：如果 K 可以隐式转换为 T，那么它也可以隐式转换为 T。这会引入任何新的隐式转换吗？当然不是。

所以也许本·沃伊特的评论是正确的；也许您所询问的这些要点最好放在脚注中，而不是放在正文中。无论如何，我很清楚它们是多余的，因此从前提开始它们不能是多余的，否则它们就不会在那里就是开始执行一项愚蠢的任务。愿意接受这样一个事实：冗余的陈述可能仍然可以阐明一个对每个人来说可能并不明显的概念，并且更容易接受这些陈述的本来面目。

多余的？是的。同义反复？是的。无意义？ 我认为，不。

_{*显然，我没有参与编写 C# 语言规范。如果我这样做的话，这个答案就会更加权威。事实上，它只是代表一个人试图理解一份相当复杂的文档的无力尝试。}

---

原始答案

我认为你（也许是故意的）忽略了这里最明显的答案。

考虑你的问题中的这两句话：

(1) 最初它们看起来是多余的
（同义反复）。 (2)但他们必须在那里
出于某种目的，那么他们为什么在那里？

对我来说，这两句话放在一起的含义是同义反复的陈述没有任何意义。但仅仅因为一个陈述是从既定前提逻辑上得出的，并不会让每个人都明白这一点。换句话说，即使(1)为真，(2)的答案可能只是：让阅读规范的任何人都清楚所描述的行为< /em>.

现在您可能会争辩说，即使某些内容不是显而易见的，但如果它提供了冗余定义，它仍然不属于规范。对于这种潜在的反对意见，我只能说：现实一点。 （在我看来）梳理一份文件并剔除所有陈述是不太实际的，这些陈述只是陈述可以从先前陈述中推断出的事实。

如果这是一种常见的做法，我想你会发现很多文献——不仅仅是规格，还有研究论文、文章、教科书等——会短很多，更密集，更难理解。

所以：是的，也许它们是多余的。但这并不能否定他们的目的。

Answer 2

规范第 4.7 节指出，存在从 Foo 到 Foo

人们可能会合理地指出（1）这些短语的意图不明显 - 因此你的问题 - 并且令人困惑，并且（2）有关身份转换的部分应该交叉引用有关动态转换的部分，以及（3）短语规范中的这种情况使得规范的实现者很难将规范语言清楚地转换为实现。如何知道是否存在这种类型？规范不需要指定确切的算法，但如果它能提供更多指导那就太好了。

遗憾的是，该规范并不是一个完美的文档。

Answer 3

身份转换从
任何类型到相同类型。这
存在转换使得实体
已经有所需的类型可以
据说可以转换成
类型。

这表示在 C# 领域，1==1；黑桃就是黑桃。这是将对象引用分配给相同类型的变量的基础；如果一个类型为 T1 的变量和一个类型为 T2 的变量实际上都是 Spade，则可以将一个变量分配给另一个变量，而无需将其中一个显式转换为 Spade。想象一个 C# 变体，其中赋值必须如下所示：

Spade mySpade = new Spade();
Spade mySpade2;

mySpade2 = (Spade)mySpade; //explicit cast required

此外，数学中的“恒等式”指出，在给定一组输入的情况下求出结果的表达式相当于在给定相同输入的情况下生成相同结果的另一个表达式。在编程中，这意味着计算结果为类型实例的表达式或函数与该类型等效，无需显式转换。如果这不成立，则需要以下代码：

public int myMethod() { /*Do something*/ }
...
int myInt = (int)myMethod(); //required even though myMethod() evals to an int.
...
int myInt = (int)(1 + 2); //required even though 1, 2, and 1+2 eval to an int.

第二条规则基本上说，如果成员变量（根据定义是装箱类型，因为其容器是引用类型）被声明为相同类型。如果未指定此规则，理论上，可能存在一个 C# 版本，其中纯值类型必须显式转换为其引用模拟，以便作为成员变量存储在类中。例如，想象一下 C# 的一个版本，其中蓝色关键字类型（int、float、decimal）和浅蓝色类名（Int32、Float、Decimal）引用两种截然不同的、只能显式转换的类型，而 int 、 float、decimal 等作为成员变量类型是不合法的，因为它们不是引用类型：

public class MyClass
{
  Int32 MyBoxedValueType; //using "int" not legal
}

...

MyClass myClass = new MyClass();
int theInt = 2;

myClass.MyBoxedValueType = (Int32)theInt; //explicit cast required

我知道这听起来很愚蠢，但在某种程度上，这些东西必须是已知的，在计算机中，你必须指定一切。有时阅读美国冰球协会的冰球规则手册；书中的第一条规则是比赛必须在冰面上进行。这是终极的“好吧”之一，但也是游戏的基本真理，必须理解它才能使任何其他规则有意义。

Answer 4

愿代码在像 Convert.ChangeType(client, typeof(Client)) 那样调用时保证传递，无论是否实现了 IConvertible 。

使用 Reflector 查看 mscorlib 中 ChangeType 的源代码，并注意按原样返回 value 的条件。

请记住，= 运算符不是转换，只是一个引用集。因此，像 Client client_2 = client_1 这样的代码不会执行任何隐式转换。如果声明了身份隐式转换，则会出现错误 CS0555 已发布。

我猜规范说让 C# 编译器处理此类情况，因此不要手动尝试定义身份转换。