为什么不在 Swift 中使用可选项？

Question

我正在阅读有关如何在 Swift 中编程的内容，但可选项的概念让我有些烦恼。并不是说为什么要使用可选项，这是有道理的，但更重要的是在什么情况下您不想使用可选项。据我了解，可选项只允许将对象设置为 nil，那么您为什么不想要该功能呢？将对象设置为零不是您告诉 ARC 释放对象的方式吗？ Foundation 和 Cocoa 中的大多数函数不都返回可选项吗？因此，除了每次都必须输入一个额外的字符来引用一个对象之外，还有什么好的理由不使用可选项来代替常规类型？

Answer 1

不使用可选的理由有很多。主要原因：你想表达一个值必须是可用的。例如，当您打开文件时，您希望文件名是字符串，而不是可选字符串。使用nil 作为文件名根本没有意义。

我将考虑两个主要用例：函数参数和函数返回值。

对于函数参数，以下内容成立：如果需要提供参数，则不应使用选项。如果提交 nothing 没问题并且是有效的（记录在案的！）输入，则提交可选的。

对于不返回可选值的函数返回值特别好：你向调用者保证他将收到一个对象，而不是一个对象或什么都没有。当您不返回可选项时，调用者知道他可能会立即使用该值，而不是先检查 null。

例如，考虑一个工厂方法。这样的方法应该总是返回一个对象，那么为什么要在这里使用 optional 呢？这样的例子比比皆是。

实际上，大多数 API 应该使用非可选项而不是可选项。大多数时候，简单地传递/接收可能什么都没有并不是你想要的。在极少数情况下没有任何选择。

必须彻底记录使用 optional 的每种情况：在哪些情况下方法将不返回任何内容？什么时候可以什么都不交给方法，后果是什么？大量的文档开销。

还有简洁性：如果您使用的 API 到处都使用 optional，那么您的代码将被空检查弄得一团糟。当然，如果每次使用 optional 都是有意的，那么这些检查是好的和必要的。但是，如果 API 只使用 optional 是因为它的作者很懒惰并且只是到处使用 optional，那么检查是不必要的，纯粹是样板文件。

但要小心！

我的回答听起来好像选项的概念很糟糕。反之亦然！通过拥有像可选项这样的概念，程序员能够声明是否可以不提交/不返回任何内容。函数的调用者总是知道这一点，并且编译器会强制执行安全。将其与普通的旧 C 进行比较：您无法声明指针是否可以是 null。您可以添加说明它是否可能是 null 的文档 cmets，但编译器并未强制执行此类 cmets。如果调用者忘记检查返回值是否为 null，则您收到了段错误。使用可选项，您可以确定没有人再取消引用 null 指针了。

总之，空安全类型系统是现代编程语言的主要进步之一。

Answer 2

可选项的最初想法（早在 Swift 之前就已经存在）是强制程序员在使用 nil 之前检查它的值——或者防止外部代码在不允许的地方传递 nil。软件崩溃的很大一部分，甚至可能是大多数，都发生在地址 0x00000000（或 NullPointerException 等），正是因为它太容易忘记零指针场景。 （2009 年，Tony Hoare 为发明空指针道歉）。

不使用可选项与使用它们一样有效和广泛的用例：当值绝对不能丢失时，应该有非可选类型；如果可以，应该有一个可选的。

但是目前，现有的框架是用 Obj-C 编写的，没有考虑到可选项，因此在 Swift 和 Obj-C 之间自动生成的桥梁只是必须接受和返回可选项，因为不可能自动深入分析每个方法并找出哪些参数和返回值应该是可选的。我敢肯定，随着时间的推移，Apple 会手动修复每一个出错的情况。现在你不应该以这些框架为例，因为它们绝对不是一个好的框架。 （对于很好的例子，您可以查看像 Haskell 这样的流行函数式语言，它从一开始就具有可选项）。