为什么 .NET 中存在 null？

Question

为什么 .NET 中的值可以为 null？这是否优于保证所有东西都有值且没有东西为空的保证？

有人知道这些方法的名称是什么吗？

不管怎样，我对此不是很了解，但就简单性而言，并不是所有东西都有一个值会让事情变得更容易，即消除空检查，并能够编写更精简的算法，而不必分支用于检查。

每种风格在性能、简单性、并行性、面向未来等方面都有哪些优缺点？

Answer 1

我们有 Tony Hoare，他是 Algol 的早期先驱为此表示感谢。他颇为遗憾：

我称之为我的十亿美元错误。
这是零的发明
1965年的参考文献。当时，我
设计第一个综合类型
对象中的引用系统
面向语言（ALGOL W）。我的目标
是为了确保所有使用
参考文献应该绝对安全，
自动执行检查
由编译器。但我无法抗拒
放入 null 的诱惑
参考，只是因为它是如此
易于实施。这导致了
无数的错误、漏洞、
和系统崩溃，这有
可能造成了十亿美元的损失
过去四十年的痛苦和伤害
年。

我认为十亿是一个偏低的数字。

---

更新：C# 版本 8 和 .NETCore 对于此问题有一个不错的解决方案，请查看 不可为 null 的引用类型。

Answer 2

尽管没有 null 的世界很有吸引力，但它确实给许多现有模式和构造带来了很多困难。例如，考虑以下构造，如果 null 不存在，则需要进行重大更改

1. 创建引用类型 ala 的数组：new object[42]。在现有的 CLR 世界中，数组将用 null 填充，这是非法的。数组语义在这里需要进行相当大的改变，
2. 只有当 T 是值类型时，它才使 default(T) 有用。不允许在引用类型或不受约束的泛型上使用它
3. 。结构中作为引用类型的字段需要被禁止。现在，在 CLR 中可以将值类型初始化为 0，这样可以方便地使用 null 填充引用类型的字段。这在非空世界中是不可能的，因此需要禁止类型为结构中引用类型的字段。

上述问题都不是无法解决的，但它们确实会导致真正挑战开发人员如何思考编码的变化。就我个人而言，我希望 C# 和 .Net 的设计能够消除 null，但不幸的是事实并非如此，我想像上面这样的问题与此有一定关系。

Answer 3

这让我想起詹姆斯·伯克的《连线》系列中的一集，僧侣们将阿拉伯语抄写成拉丁语，第一次遇到了零数字。罗马算术没有零的表示，但阿拉伯/阿拉姆算术有。 “为什么我们一定要写信表明什么？”天主教修士们争论道。 “如果没什么，我们就什么也不写！”

对于现代社会来说幸运的是，他们输掉了争论并学会了在数学中写出零数字。 ;>

Null 只是表示不存在对象。有些编程语言本身没有“null”，但大多数语言仍然有一些东西来表示合法对象的不存在。如果你扔掉“null”并将其替换为“EmptyObject”或“NullNode”，它仍然是一个 null，只是名称不同。

如果你删除了编程语言表示不引用合法对象的变量或字段的能力，也就是说，你要求每个变量和字段始终包含一个真实有效的对象实例，那么你就做出了一些非常有用和高效的东西。数据结构笨拙且低效，例如构建链表。程序员被迫发明“假”对象实例来充当列表终端，而不是使用 null 来指示链表的末尾，该实例除了指示“这里什么都没有”之外什么都不做。

在这里深入研究存在主义，但是：如果你可以代表某物的存在，那么是否也有基本的需要能够代表它的不存在？

Answer 4

我推测它们在.NET中存在null，因为它（C#）追随了C++/Java的脚步（并且只在更新的版本中开始分支） ）和 VB/J++（后来成为 VB.NET/J#）已经有了“无”值的概念——也就是说，.NET 有 null 因为曾经而不是因为它可能是什么。

在某些语言中，没有 null 的概念 - null 可以完全替换为 Maybe 之类的类型 - - 有 Something（对象）或 Nothing（但这不是 null！没有办法从 Maybe 中得到“Nothing”！）

在 Scala 中选项：

val opt = Some("foo") // or perhaps, None
opt match {
   case Some(x) => x.toString() // x not null here, but only by code-contract, e.g. Some(null) would allow it.
   case _ => "nothing :(" // opt contained "Nothing"
}

这是通过 Haskell 中的语言设计（null 不可能......根本！）和通过库支持和仔细使用来完成的，例如与 Scala 中一样，如上所示。 （Scala 支持 null——可以说是为了 Java/C# 互操作——但是可以在不使用这个事实的情况下编写 Scala 代码，除非允许“泄漏”null） 。

编辑：请参阅Scala：选项模式 、 Scala：选项 Cheat Cheet 和 SO：在 Haskell 中使用 Maybe Type。大多数时候在 Haskell 中谈论 Maybe 都会提到 Monad 的话题。我不会声称理解它们，但是这里有一个链接以及使用也许吧。

快乐编码。

Answer 5

好的，现在换行到 C#-without-null 的魔术词

class View
{
    Model model;        

    public View(Model model)
    {
        Console.WriteLine("my model : {0}, thing : {1}", this.model, this.model.thing);
        this.model = model;
    }
}

控制台上打印了什么？

• 访问未初始化的对象不会引发任何异常：好吧，将其称为 NullReferenceException，这就是当前的世界。
• 它不会构建，用户需要在声明模型时指定一个值，请参阅最后一个要点，因为它会创建相同的结果。
• 模型的一些默认值和事物的一些默认值：好吧，在使用 null 之前，我们至少有一种方法可以知道实例是否正确，现在编译器正在生成奇怪的相似项，它们不包含任何内容，但作为模型仍然无效对象...
• 由对象类型定义的东西：更好的是，我们可以为每个对象定义一个特定的无效状态，但现在每个可能无效的对象都需要独立实现它以及调用者识别此状态的方法。所以

基本上对我来说，它似乎没有解决任何删除空状态的问题，因为无论如何仍然需要管理可能无效的状态......

哦，购买接口的默认值是什么？哦，还有一个抽象类，当对抽象类中定义的默认值调用一个方法但调用另一个抽象方法时会发生什么？ .... .... 为什么哦为什么让模型变得毫无意义，这又是多重继承问题！

一种解决方案是完全更改语法，以实现功能齐全的语法，其中空世界不存在，只有当您希望它们存在时才可能存在......但它不是一种类似 C 的语言和多范式.Net 的内容将会丢失。

可能缺少的是一个 null 传播运算符，当 model 为 null 时，它能够将 null 返回给 model.Thing，例如 model.?.Thing

---

哦，为了更好地确定答案回答你的问题：

• 当前的类库是在 Microsoft-Java 崩溃之后发展起来的，并且 C# 被构建为“更好的 Java”，因此更改类型系统以删除空引用将是一个很大的变化。他们已经成功引入了值类型并删除了手动装箱！
• 正如值类型介绍所示，微软对速度考虑很多......事实上，所有类型的默认映射到零填充对于快速数组初始化来说非常重要。否则，参考值数组的初始化将需要特殊的威胁。
• 如果没有与 C 的空互操作，则不可能，因此至少在 MSIL 级别和不安全块中，需要允许它们生存。
• 微软希望使用 VB6++ 框架来删除 Nothing，因为它在 VB 中被称为“Nothing”，这会从根本上改变语言，用户从 VB6 切换到 VB.Net 已经花了很多年的时间，这样的范式变化可能会对于语言来说是致命的。

Answer 6

嗯，值（值类型变量）只能为null，因为可空类型是在 Fx2 中引入的。

但我想你的意思是：

为什么引用可以为 null ？

这就是参考文献的部分用处。考虑一个 Tree 或 LinkedList，如果没有 null，它们就不可能（无法结束）。

您还可以举出更多示例，但主要是 null 的存在是为了对“可选”属性/关系的概念进行建模。

Answer 7

歇斯底里的葡萄干。

这是 C 级语言的后遗症，在 C 级语言中，您依赖于显式的指针操作。现代声明性语言（Mercury、Haskell、OCaml 等）在没有 null 的情况下运行得非常愉快。在那里，每个值都必须显式构造。 “null”的想法是通过“option”类型来处理的，该类型有两个值：“no”（对应于 null）和“yes(x)”（对应于值为 x 的非 null）。您必须解压缩每个选项值才能决定要做什么，因此：没有空指针引用错误。

语言中没有空值可以让你省去很多麻烦，这种想法在高级语言中仍然存在，这确实是一种耻辱。

Answer 8

我也不熟悉替代方案，但我没有看到 Object.Empty 和 null 之间的区别，除了 null 让您知道当您的代码尝试访问对象时出现了问题，而 Object.Empty 允许处理继续。有时您想要一种行为，有时您想要另一种行为。区分 null 和 Empty 是一个有用的工具。

Answer 9

表示虚无概念，因为 0 不合适。

现在，您可以通过定义可为 null 的类型为任何值类型指定 Null 值。

我认为我们不能总是为变量指定一个值，因为首先我们必须将其默认为某个值，这就出现了为什么特定值比其他值更具优势的问题。

Answer 10

许多人可能无法理解没有空值的编码，如果 C# 没有空值，我怀疑它是否会流行到这样的程度。

话虽这么说，一个不错的选择是，如果您想允许可为空引用，则该引用必须显式可为空，就像值类型一样。

例如，

Person? person = SearchForPersonByFirstName("Steve");
if (person.HasValue)
{
    Console.WriteLine("Hi, " + person.Value.FullName);
}

不幸的是，C# 1.0 出来时，还没有 Nullable 的概念；这是 C# 2.0 中添加的。强制引用具有值会破坏旧程序。

Answer 11

null 只是引用类型的默认值的名称。如果不允许 null ，那么“没有值”的概念不会消失，您只需以不同的方式表示它即可。除了具有特殊的名称之外，此默认值在被误用的情况下还具有特殊的语义 - 即，如果您将其视为有值，而实际上没有值。

如果没有 null：

1. 您需要为您的类型定义哨兵默认值，以便在“没有值”时使用。作为一个简单的示例，请考虑前向单链表的最后一个节点。
2. 您需要为对所有这些标记值执行的操作定义语义。
3. 运行时会产生额外的开销来处理标记值。在现代虚拟机中，例如 .NET 和 Java 使用的虚拟机，在大多数函数调用和取消引用之前没有空检查的开销，因为 CPU 提供了特殊的方法来处理这种情况，并且 CPU 针对以下情况进行了优化：引用非空（例如分支预测）。

总之：

• 名称会改变，但概念不会改变。
• 在“没有价值”的情况下定义和传达默认值和语义的负担由开发人员和开发人员文档承担。
• 在现代虚拟机上执行的代码将面临代码膨胀和许多算法的性能大幅下降。

Tony Hoare 描述的 null 问题通常是由于以下事实造成的：在现代虚拟机出现之前，运行时系统没有像您这样干净地处理误用的 null 值有今天。滥用指针/引用确实仍然是一个问题，但是在使用 .NET 或 Java 时跟踪问题往往比以前在 C 中容易。