我正在阅读如何在Swift中编程，而且可选项的概念让我有点烦恼。对于为什么使用选项而言并不是真的，这是有道理的，但更多的是在什么情况下你不想使用选项。根据我的理解，一个可选项只允许将一个对象设置为nil，那你为什么不想要这个功能呢？是不是将对象设置为n告诉ARC释放对象的方式为零？并且基金会和Cocoa中的大部分功能都没有返回选项吗？因此，除了每次引用一个对象时都要输入一个额外的字符，有没有什么好的理由不使用可选代替常规类型？
答案 0 :(得分：7)
有很多理由不使用可选项。主要原因：你想表达一个值必须可用。例如，当您打开文件时，您希望文件名是字符串，而不是可选字符串。使用nil作为文件名是没有意义的。
我将考虑两个主要用例：函数参数和函数返回值。
对于函数参数，以下成立：如果需要提供参数，则不应使用选项。如果输入没有是可以的并且是有效的（记录！）输入，那么请输入一个可选项。
对于函数返回值，返回no optional是特别好的：你向调用者保证他将接收一个对象，而不是一个对象或 nothing 。当你没有返回一个可选项时，调用者知道他可以立即使用该值而不是先检查null。
例如，考虑工厂方法。这样的方法应该总是返回一个对象，那么为什么要在这里使用可选项呢？有很多这样的例子。
实际上，大多数API应该使用非选项而不是选项。大多数情况下，简单地传递/接收 nothing 并不是你想要的。很少有案例没有选择。
必须彻底记录每个使用可选项的情况：在哪种情况下，方法什么都不返回？什么时候可以不用任何方法，后果是什么？很多文档开销。
然后还有简洁性：如果您使用的是遍布整个地方的可选API，那么您的代码将会被空检查所混乱。当然，如果每次使用可选项都是有意的，那么这些检查就很好并且是必要的。但是，如果API仅使用可选项，因为它的作者是懒惰的，并且只是在整个地方使用可选项，那么检查是不必要的和纯粹的样板。
我的回答可能听起来好像选项的概念很糟糕。反之亦然！通过像选项一样的概念，程序员能够声明是否可以输入/返回任何内容。函数的调用者始终意识到这一点并且编译器强制执行安全性。将其与普通旧C进行比较：您无法声明指针是否为null。您可以添加文档注释，说明它是否为null，但编译器不强制执行此类注释。如果调用者忘记检查null的返回值，则会收到段错误。使用选项，您可以确保没有人再取消引用null指针。
总而言之，零安全类型系统是现代编程语言的主要进步之一。
答案 1 :(得分：2)
选项的最初想法（在Swift之前很久就存在）是强制程序员在使用之前检查nil的值 - 或者防止外部代码在不允许的情况下传递nil。软件中很大一部分崩溃，甚至可能是其中大部分崩溃都发生在地址0x00000000（或者与NullPointerException或类似），因为它太容易忘记nil-pointer场景。 （2009年，Tony Hoare因发明空指针而道歉。）
不使用optionals就像使用它们一样有效和广泛使用：当绝对不能丢失值时，应该有非可选类型;如果可以，应该有一个可选的。
但是目前，现有的框架是用Obj-C编写的，没有选项，所以在Swift和Obj-C之间自动生成的桥梁只需有来获取和返回选项，因为它是不可能的自动深入分析每个方法，并找出哪些参数和返回值应该是选项。我相信随着时间的推移，Apple会手动修复他们弄错的每一个案例;现在你不应该使用这些框架作为例子，因为它们绝对不是一个好的框架。 （举个很好的例子，你可以检查像Haskell这样的流行函数语言，从一开始就有选项）。