演员 vs “as”重新审视运营商

Question

我知道已经有几篇文章涉及强制转换和 as 运算符之间的区别。它们大多都重申了相同的事实：

• as 运算符不会抛出异常，但如果转换失败则返回 null
• 因此，as 运算符只能起作用对于引用类型
• as 运算符不会使用用户定义的转换运算符

然后答案往往会无休止地争论如何使用或不使用其中一个以及每个的优缺点，甚至它们的性能（我一点也不感兴趣）。

但这里还有更多的事情在起作用。想一想：

static void MyGenericMethod<T>(T foo)
{
    var myBar1 = foo as Bar;  // compiles
    var myBar2 = (Bar)foo;    // does not compile ('Cannot cast expression of
                              // type 'T' to type 'Bar')
}

请不要介意这个明显令人悔恨的例子是否是好的做法。我在这里担心的是两者之间非常有趣的差异，因为强制转换不会编译，而 as 可以编译。我真的很想知道是否有人可以对此有所了解。

正如人们经常指出的那样，as 运算符忽略用户定义的转换，但在上面的示例中，它显然是两者中更强大的一个。请注意，就编译器而言，（编译时未知）类型 T 和 Bar 之间没有已知的联系。演员阵容完全是“运行时”的。我们是否应该怀疑强制转换在编译时已全部或部分解析，而 as 运算符则没有？

顺便说一句，添加类型约束毫不奇怪地修复了强制转换，因此：

static void MyGenericMethod<T>(T foo) where T : Bar
{
    var myBar1 = foo as Bar;  // compiles
    var myBar2 = (Bar)foo;    // now also compiles
}

为什么 as 运算符可以编译，而强制转换却不能编译？

Answer 1

要解决您的第一个问题：不仅仅是 as 运算符忽略用户定义的转换，尽管这是相关的。更相关的是强制转换运算符做了两件相互矛盾的事情。强制转换运算符意味着：

1. 我知道这个编译时类型 Foo 的表达式实际上是运行时类型 Bar 的对象。编译器，我现在告诉你这个事实，以便你可以利用它。请假设我是正确的生成代码；如果我不正确，那么你可能会在运行时抛出异常。

2. 我知道这个编译时类型 Foo 的表达式实际上是运行时类型 Foo。有一种标准方法可以将 Foo 的部分或全部实例转换为 Bar 的实例。编译器请生成这样一个转换，如果在运行时发现被转换的值不可转换，则在运行时抛出异常。

这些是相反。巧妙的技巧，让一个操作符做相反的事情。

相比之下，as 运算符仅具有第一种含义。 as 仅执行装箱、拆箱 和表示保留 转换。强制转换可以完成所有这些操作以及额外的表示更改转换。例如，将 int 转换为 Short 会将表示形式从四字节整数更改为两字节整数。

这就是为什么“原始”强制转换对于不受约束的泛型是不合法的。因为编译器没有足够的信息来确定它是什么类型的转换：装箱、拆箱、保留表示或更改表示。用户的期望是泛型代码中的强制转换具有更强类型代码中强制转换的所有语义，而我们无法有效地生成该代码。

考虑一下：

void M<T, U>(T t, out U u)
{
    u = (U)t;
}

你希望这有效吗？我们生成哪些代码可以处理：

M<object, string>(...); // explicit reference conversion
M<string, object>(...); // implicit reference conversion
M<int, short>(...); // explicit numeric conversion
M<short, int>(...); // implicit numeric conversion
M<int, object>(...); // boxing conversion
M<object, int>(...); // unboxing conversion
M<decimal?, int?>(...); // lifted conversion calling runtime helper method
// and so on; I could give you literally hundreds of different cases.

基本上，我们必须为测试发出代码，再次启动编译器，对表达式进行全面分析，然后发出新代码。我们在 C# 4 中实现了该功能；它被称为“动态”，如果这是您想要的行为，您可以随意使用它。

as 不存在这些问题，因为 as 只做了三件事。它执行装箱转换、拆箱转换和类型测试，我们可以轻松生成执行这三件事的代码。

Answer 2

我们是否应该怀疑演员阵容
在编译时全部或部分解决
time 和 as 运算符不是吗？

您在问题开始时自己给出了答案：“as 运算符不会使用用户定义的转换运算符” - 同时，强制转换会，这意味着它需要找到这些运算符（ >或它们不存在）在编译时。

请注意，就编译器而言
所关心的是，没有已知的
之间的连接（未知
编译时）类型 T 和 Bar。

T 类型未知这一事实意味着编译器无法知道它和Bar之间是否没有联系。

请注意，(Bar)(object)foo 确实有效，因为没有类型可以有到 Object 的转换运算符[因为它是所有东西的基类]，并且从 object 到 Bar 的转换已知不必处理转换运算符。

Answer 3

这是类型安全的问题。
任何 T 都不能转换为 Bar，但任何 T 都可以“视为”作为 Bar，因为即使没有从 T 到 Bar 的转换，行为也已明确定义。

Answer 4

第一个编译器之所以能够编译，是因为 as 关键字就是这样定义的。如果无法转换，它将返回null。它是安全的，因为 as 关键字本身不会导致任何运行时问题。您可能已检查或未检查变量是否为空这一事实是另一回事。

将 as 视为 TryCast 方法。

Answer 5

编译器不知道如何生成适用于所有情况的代码。

考虑这两个调用：

MyGenericMethod(new Foo1());
MyGenericMethod(new Foo2());

现在假设 Foo1 包含一个强制转换运算符，可以将其转换为 Bar 实例，并且 Foo2 源自 >Bar 代替。显然，所涉及的代码在很大程度上取决于您传入的实际 T 。

在您的特定情况下，您说该类型已经是 Bar 类型，因此显然编译器可以这样做引用转换，因为它知道这是安全的，没有正在进行或不需要的转换。

现在，as 转换更具“探索性”，它不仅不考虑用户转换，而且明确允许强制转换毫无意义的事实，因此编译器对此不予理睬。