奇怪的空合并运算符自定义隐式转换行为

感谢所有为分析此问题做出贡献的人。这显然是一个编译器错误。它似乎只发生在合并运算符左侧涉及两个可空类型的提升转换时。

我还没有确定到底哪里出了问题，但是在编译的“可空降低”阶段的某个时刻——在初始分析之后但在代码生成之前——我们减少了表达式

result = Foo() ?? y;

从上面的例子到道德上的等价物：

A? temp = Foo();
result = temp.HasValue ? 
    new int?(A.op_implicit(Foo().Value)) : 
    y;

显然这是不正确的；正确的降低是

result = temp.HasValue ? 
    new int?(A.op_implicit(temp.Value)) : 
    y;

到目前为止，根据我的分析，我最好的猜测是可空优化器在这里偏离了轨道。我们有一个可为 null 的优化器，它查找我们知道可为 null 类型的特定表达式不可能为 null 的情况。考虑以下简单的分析：我们可以先说

result = Foo() ?? y;

是相同的

A? temp = Foo();
result = temp.HasValue ? 
    (int?) temp : 
    y;

然后我们可以说

conversionResult = (int?) temp 

是相同的

A? temp2 = temp;
conversionResult = temp2.HasValue ? 
    new int?(op_Implicit(temp2.Value)) : 
    (int?) null

但是优化器可以介入并说“哇，等一下，我们已经检查了 temp 不为空；没有必要因为我们调用提升的转换运算符而第二次检查它是否为空”。我们让他们将其优化为

new int?(op_Implicit(temp2.Value)) 

我的猜测是，我们在某个地方缓存了 (int?)Foo() 的优化形式是 new int?(op_implicit(Foo().Value)) 的事实，但这实际上并不是我们想要的优化形式；我们想要 Foo()-replaced-with-temporary-and-then-converted 的优化形式。

C# 编译器中的许多错误都是由于错误的缓存决策造成的。对智者的一句话：每次你缓存一个事实供以后使用时，如果相关的事情发生变化，你可能会造成不一致。在这种情况下，初始分析后改变的相关事情是对 Foo() 的调用应始终实现为临时获取。

我们在 C# 3.0 中对可为空的重写过程进行了大量重组。该错误在 C# 3.0 和 4.0 中重现，但在 C# 2.0 中没有重现，这意味着该错误可能是我的错误。对不起！

我会在数据库中输入一个错误，我们会看看我们是否可以为该语言的未来版本修复这个错误。再次感谢大家的分析；这很有帮助！

更新：我从头开始为 Roslyn 重写了可为空的优化器；它现在做得更好，并避免了这些奇怪的错误。有关 Roslyn 中的优化器如何工作的一些想法，请参阅我从这里开始的系列文章：https://ericlippert.com/2012/12/20/nullable-micro-optimizations-part-one/

---

这绝对是一个错误。

public class Program {
    static A? X() {
        Console.WriteLine("X()");
        return new A();
    }
    static B? Y() {
        Console.WriteLine("Y()");
        return new B();
    }
    static C? Z() {
        Console.WriteLine("Z()");
        return new C();
    }

    public static void Main() {
        C? test = (X() ?? Y()) ?? Z();
    }
}

此代码将输出：

X()
X()
A to B (0)
X()
X()
A to B (0)
B to C (0)

这让我觉得每个 ?? 合并表达式的第一部分都被计算了两次。这段代码证明了这一点：

B? test= (X() ?? Y());

输出：

X()
X()
A to B (0)

这似乎只在表达式需要在两个可空类型之间进行转换时才会发生；我尝试了各种排列，其中一侧是字符串，但没有一个导致这种行为。

---

如果您查看为 Left-grouped 案例生成的代码，它实际上会执行以下操作 (csc /optimize-)：

C? first;
A? atemp = a;
B? btemp = (atemp.HasValue ? new B?(a.Value) : b);
if (btemp.HasValue)
{
    first = new C?((atemp.HasValue ? new B?(a.Value) : b).Value);
}

另一个发现，如果您使用 first，如果 a 和 b 都为 null 并返回 c，它将生成一个快捷方式。然而，如果 a 或 b 为非 null，它会在返回 a 或 b 中的哪一个为非 null 之前重新评估 a 作为到 B 的隐式转换的一部分。

来自 C# 4.0 规范，§6.1.4：

如果可空转换来自 S? to T?：如果源值为null（HasValue 属性为false），则结果为T? 类型的null 值。否则，转换被评估为从 S? 展开。到 S，然后是从 S 到 T 的基础转换，然后是从 T 到 T 的包装（第 4.1.10 节）。

这似乎解释了第二个展开-包裹组合。

C# 2008 和 2010 编译器生成非常相似的代码，但这看起来像是 C# 2005 编译器 (8.00.50727.4927) 的回归，它为上述生成以下代码：

A? a = x;
B? b = a.HasValue ? new B?(a.GetValueOrDefault()) : y;
C? first = b.HasValue ? new C?(b.GetValueOrDefault()) : z;

我想知道这是否不是由于类型推理系统的额外魔法？

---

实际上，我现在将其称为错误，并提供更清晰的示例。这仍然成立，但双重评价肯定不好。

似乎 A ?? B 被实现为 A.HasValue ? A : B。在这种情况下，也有很多转换（遵循三元 ?: 运算符的常规转换）。但是，如果您忽略所有这些，那么根据它的实现方式，这是有道理的：

一个 ？？ B 扩展到 A.HasValue ？ A : BA 是我们的 x ??是的。展开到 x.HasValue : x ? y 替换所有出现的 A -> (x.HasValue : x ? y).HasValue ? (x.HasValue : x ? y) : B

在这里您可以看到 x.HasValue 被检查了两次，如果 x ?? y 需要强制转换，则 x 将被强制转换两次。

我将它简单地描述为如何实现 ??，而不是编译器错误。 要点：不要创建具有副作用的隐式转换运算符。

这似乎是一个围绕如何实现 ?? 的编译器错误。要点：不要嵌套具有副作用的合并表达式。

---

从我的问题历史中可以看出，我根本不是 C# 专家，但是，我试过了，我认为这是一个错误....但是作为一个新手，我不得不说我不明白一切在这里，如果我离开了，我会删除我的答案。

我通过制作处理相同场景但简单得多的程序的不同版本得出了这个 bug 结论。

我将三个空整数属性与后备存储一起使用。我将每个设置为 4，然后运行 int? something2 = (A ?? B) ?? C;

(Full code here)

这只是读取 A 而没有别的。

在我看来，这句话应该：

从括号开始，查看 A，返回 A，如果 A 不为 null，则结束。如果 A 为 null，则评估 B，如果 B 不为 null，则完成如果 A 和 B 为 null，则评估 C。

因此，由于 A 不为空，它只查看 A 并完成。

在您的示例中，在第一种情况下放置断点表明 x、y 和 z 都不为空，因此，我希望它们与我不太复杂的示例一样被对待....但我担心我太多了一个 C# 新手，完全错过了这个问题的重点！

---