C# 类型推断 ("var") 从 '??' 空合并运算符赋值

Question

我已经阅读了许多关于空合并 ?? 运算符的 SO 问题，但它们似乎都没有解决以下特定问题，这既不涉及可空性( here )、运算符优先级( here 和 here )，尤其是隐式转换( here 、 here 、 here 和 here ).我还阅读了 .NET docs (更多 here )并尝试阅读 offical spec ，但遗憾的是，一切都无济于事。

---

就这样吧。以下两行之间的唯一区别是在第二行中使用 var 进行类型推断，而在第一行中使用显式类型 Random，但第二行给出的错误为显示，而第一个就好了。

Random x = new Random() ?? (x = new Random());        // ok

var    y = new Random() ?? (y = new Random());        // CS0841
                        //  ^-------- error here

CS0841: Cannot use local variable 'y' before it is declared

第二行究竟是什么让结果变得不确定？

从我上面引用的 hubub 中，我了解到 ?? 运算符的左侧为 null 的可能性引入了对运行时确定的依赖性其右侧的实际实例化类型。嗯，好吧，我猜，……什么意思？也许这个网站上关于 ?? 运营商的警报数量应该是某种可怕的警告......

现在归零，我认为 var 关键字(与 dynamic 截然相反)的全部意义在于它不受运行时考虑因素的影响，例如那，根据定义。

换句话说，即使我们采用保守但完全站得住脚的规则“永远不要超越任何赋值 = 运算符”，因此我们无法从右侧获得任何有用的信息??，然后仅基于左侧，总体结果必须“兼容”随机。也就是说，结果必须是 Random 或更具体(派生)的类型；它不能更笼统。因此，根据定义，对于 var 的这种编译时使用，Random 不应该是推断类型吗？

据我所知，出于运行时的考虑而破坏 var 显然会违背其目的。这不正是 dynamic 的用途吗？所以我想问题是:

• 对于我对 C# 静态(即编译时)类型哲学的理解，null-coalescing 运算符是一个孤立的和/或罕见的异常(exception)吗？
• 如果是，那么这种设计与这里似乎发生的事情(即故意将非确定性引入静态类型推断系统，并且它以前没有展示过)之间的好处或权衡是什么？难道不能在不破坏静态类型的纯度的情况下实现dynamic吗？
• 强类型的要点之一不是通过向开发人员提供可操作的反馈来实现编译时设计的严格性吗？为什么 var 不能保持严格保守的政策——总是推断可以静态推断的最具体类型——在同时空合并运算符正在根据 future 的信息做任何它想做的事情？

Answer 1

这不是运行时考虑因素。

使用 var 声明的变量的编译时类型是其初始值设定项的静态类型。 ?? 表达式的静态类型是两个操作数的静态类型的公共(public)类型。但是第二个操作数的静态类型是y的静态类型，这是未知的。因此整个初始化器的静态类型未知，推导失败。

确实存在初始化一致的类型，但无法使用 C# 推理规则找到它们。