Swift 3.0 新增安全特性的一点普及

<b>本文讲的是Swift 3.0 新增安全特性的一点普及，</b>

<b></b>

在 Swift 发布之后，Swift 的开发者一直在强调，安全性与可选择类型是 Swift 最为重要的特性之一。他们提供了一种<code>nil</code>的表示机制，并要求有一个明确的语法在可能为<code>nil</code>的实例上使用。

可选择类型主要以下两种:

<code>Optional</code>

<code>ImplicitlyUnwrappedOptional</code>

第一种做法是一种安全的做法：它要求我们去拆解可选类型变量是为了访问基础值。第二种做法是一种不安全的做法：我们可在不拆解可选择类型变量的情况下直接访问其底层值。

比如，如果在变量值为 <code>nil</code> 的时候，使用 <code>ImplicitlyUnwrappedOptional</code> 可能会导致一些异常。

下面将展示一个关于这个问题的例子：

在 Swift 3.0 中，苹果改进了 <code>ImplicitlyUnwrappedOptional</code> 的实现，使其相对于以前变得更为安全。这里我们不禁想问，苹果到底在 Swift 3.0 对 <code>ImplicitlyUnwrappedOptional</code>

做了哪些改进，从而使 Swift 变得更为安全了呢。答案在于，苹果在编译器对于 <code>ImplicitlyUnwrappedOptional</code> 进行类型推导的过程中进行了优化。

让我们来通过一个例子来理解这里面的变化。

这里我们创建了一个初始化方法有缺陷的结构体 <code>Person</code> 。如果我们在初始化中不给实例提供 <code>first name</code> 和 <code>last name</code> 的值的话，那么初始化将会失败。

在这里 <code>init!(firstName: String, lastName: String)</code> ，我们通过使用 <code>!</code> 而不是 <code>?</code> 来进行初始化的。不同于 Swift 3.0，在 Swift 2.x 中，我们用过利用 <code>init!</code> 来使用 <code>ImplicitlyUnwrappedOptional</code> 。

不管我们所使用的 <code>Swift</code> 版本如何，我们应该谨慎的使用 <code>init!</code>。一般而言，如果你能允许在引用生成的为nil的实例时所产生的异常，那么你可以使用 <code>init!</code> 。因为如果对应的实例为 <code>nil</code> 的时候，你使用 <code>init!</code> 会导致程序的崩溃。

在 <code>.*</code> 中，这个初始化方法将会生成一个 <code>ImplicitlyUnwrappedOptional&lt;Person&gt;</code> 。如果初始化失败，所有基于 <code>Person</code> 的实例将会产生异常。

比如，在 Swift 2.x 里，下面这段代码在运行时将崩溃。

请注意，由于在初始化器中存在着隐式解包，因此我们没有必要使用类型绑定（译者注1： <code>optional binding</code> ）或者是自判断链接（译者注2： <code>optional chaining</code> ）来保证 <code>nilPerson</code> 能被正常的使用。

在 Swift 3.0 中事情发生了一点微小的变化。在 <code>init!</code> 中的 <code>!</code> 表示初始化可能会失败，如果成功进行了初始化，那么生成的实例将被强制隐式拆包。不同于 Swift 2.x ，<code>init!</code> 所生成的实例是 <code>optional</code> 而不是 <code>ImplicitlyUnwrappedOptional</code> 。这意味着你需要针对不同的基础值对实例进行类型绑定或者是自判断链接处理。

在上面这个示例中，<code>nilPerson</code> 是一个 <code>Optional&lt;Person&gt;</code> 类型的实例。这意味着如果你想正常的访问里面的值，你需要对 <code>nilPerson</code> 进行拆包处理。这种情况下，手动拆包是个非常好的选择。

这种变化可能会令人疑惑。为什么使用的 <code>init!</code> 的初始化会会生成 <code>Optional</code> 类型的实例？不是说在 <code>init!</code> 中的 <code>!</code> 表示生成 <code>ImplicitlyUnwrappedOptional</code> 么？

答案是安全性与声明之间的依赖关系。在上面这段代码里（ <code>let nilPerson = Person(firstName: "", lastName: "Mathias")</code> ）将依靠编译器对 <code>nilPerson</code> 的类型进行推断。

在 Swift 2.x 中，编译器将会把 <code>nilPerson</code> 作为 <code>ImplicitlyUnwrappedOptional&lt;Person&gt;</code> 进行处理。讲道理，我们已经习惯了这种编译方式，而且它在某种程度上也是有道理的。总之一句话，在 Swift 2.x 中，想要使用 <code>ImplicitlyUnwrappedOptional</code> 的话，就需要利用 <code>init!</code> 对实例进行初始化。

然而，某种程度上来讲，上面这种做法是很不安全的。说实话，我们从没有任何钦定 <code>nilPerson</code> 应该是 <code>ImplicitlyUnwrappedOptional</code> 实例的意思，因为如果将来编译器推导出一些不安全的类型信息导致程序运行出了偏差，等于，你们也有责任吧。

Swift 3.0 解决这类安全问题的方式是在我们不是明确的声明一个 <code>ImplicitlyUnwrappedOptional</code> 时，会将 <code>ImplicitlyUnwrappedOptional</code> 作为 <code>optional</code> 进行处理。

这种做法很巧妙的一点在于限制了隐式解包的 <code>optional</code> 实例的传递。参考下我们前面关于 <code>Person</code> 的代码，同时思考下我们之前在 Swift 2.x 里的一些做法：

<code>anotherMatt</code> 是和 <code>matt</code> 一样类型的实例。你可能已经预料到这种并不是很理想的情况。在代码里，<code>ImplicitlyUnwrappedOptional</code> 的实例已经进行了传递。对于所产生的新的不安全的代码，我们务必要多加小心。

比如，在上面的代码中，我们如果进行了一些异步操作，情况会怎么样呢？

在上面这个例子中，<code>anotherMatt</code> 是一个值为 <code>nil</code> 的实例，这意味着任何直接访问他基础值的操作，都会导致崩溃。这种类型的访问确切来说是 <code>ImplicitlyUnwrappedOptional</code> 所推荐的方式。那么我们如果把<code>anotherMatt</code> 换成 <code>Optional&lt;Person&gt;</code> ，情况会不会好一些呢？

让我们在 Swift 3.0 中试试同样的代码会怎样。

如果我们没有显示声明我们生成的是 <code>ImplicitlyUnwrappedOptional</code> 类型的实例，那么编译器会默认使用更为安全的 <code>Optional</code>。

在这个变化中，最大的好处在于编译器的类型推断不会使我们代码的安全性降低。如果在必要的情况下，我们选择的一些不太安全的方式，我们必须进行显示的声明。这样编译器不会再进行自动的判断。

在某些时候，如果我们的确需要使用 <code>ImplicitlyUnwrappedOptional</code> 类型的实例，我们仅仅需要进行显示声明。

<code>runningWithScissors</code> 是一个值为 <code>nil</code> 的实例，因为我们在初始化的时候，我们给 <code>lastName</code> 了一个空字符串。

请注意，我们所声明的 <code>runningWithScissors</code> 实例是一个 <code>ImplicitlyUnwrappedOptional&lt;Person&gt;</code> 的实例。在 Swift 3.0 中，Swift 允许我们同时使用 <code>Optional</code> 和 <code>ImplicitlyUnwrappedOptional</code> 。不过我们必须进行显示声明，从而告诉编译器我们所使用的是 <code>ImplicitlyUnwrappedOptional</code> 。

不过幸运的是，编译器不再自动将 <code>safeAgain</code> 作为一个 <code>ImplicitlyUnwrappedOptionalThankfully</code> 实例进行处理。相对应的是，编译器将会把 <code>safeAgain</code> 变量作为 <code>Optional</code> 实例进行处理。这个过程中，Swift 3.0 对不安全的实例的传播进行了有效的限制。

<code>ImplicitlyUnwrappedOptional</code> 的改变可能是处于这样一种原因：我们通常在 macOS 或者 iOS 上操作利用 Objective-C 所编写的API，在这些API中，某些情况下，它们的返回值可能是为 <code>nil</code>，对于 Swift 来讲，这种情况是不安全的。

因此，Swift 正在避免这样的不安全的情况发生。非常感谢 Swift 开发者对于 <code>ImplicitlyUnwrappedOptional</code> 所进行的改进。我们现在可以非常方便的去编写健壮的代码。也许在未来某一天，<code>ImplicitlyUnwrappedOptional</code> 可能会彻底的从我们视野里消失。=

如果你想知道更多关于这方面的知识，你可以从这里this proposal获取一些有用的信息。你可以从 issue 里获得这个提案的作者的一些想法，同时通过具体的变化来了解更多的细节。同时那里也有相关社区讨论的链接。

日记本

© 著作权归作者所有

举报文章

关注

Zheaoli

写了 8390 字，被 17 人关注，获得了 12 个喜欢

如果觉得我的文章对您有用，请随意赞赏。您的支持将鼓励我继续创作！

作者：Zheaoli

链接：http://www.jianshu.com/p/52f8e00acc16

來源：简书

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

<b>原文发布时间为：2016年07月10日</b>

<b>本文来自云栖社区合作伙伴掘金，了解相关信息可以关注掘金网站。</b>