Collections in Swift 4

概述在Swift 4中，对原有的Collection体系做了一些简化。为此，通过这个系列，我们重新过一遍和Collection相关的内容。在这个系列里，我们抛开Swift中那些具体的Array，Set，Dictionary不谈，单纯从表达一系列元素这个概念出发，来回顾Swift Collections设计的前前后后，为什么需要Iterator？Index和Iterator的关系和区别是什么？为什么需要 在Swift 4中，对原有的Collection体系做了一些简化。为此，通过这个系列，我们重新过一遍和Collection相关的内容。在这个系列里，我们抛开Swift中那些具体的Array，Set，Dictionary不谈，单纯从表达一系列元素这个概念出发，来回顾Swift Collections设计的前前后后，为什么需要Iterator？Index和Iterator的关系和区别是什么？为什么需要Sequence？Collection和Sequence的差别是什么？如何为不同的集合类型设计接口？。通过对这些问题的讨论，你不仅能够通这个系列的内容更好的使用集合类型。还能以一个标准库库设计者的视角，来理解一些你可能平时不太会注意到的细节。 从迭代一系列元素开始

泊学4K视频
泊阅文档

在Swift 4中，对原有的Collection体系做了一些简化。为此，通过这个系列，我们重新过一遍和Collection相关的内容。

抛开Swift中那些具体的Array，Set，Dictionary不谈，单纯从为了表达一堆数字这个角度来看，其中最基础的动作，就是要能逐个访问到它们。因此，我们关于集合这个抽象概念本身的话题，不妨就从这个动作开始。

这里我们用“一堆数字”这个形式举例便于理解，实际上，作为集合，它表达的是任意一堆对象。

从约束一个最基本的遍历动作开始

为了用最简单的形式描述“逐个访问”这个动作，我们可以定义一个Protocol：

protocol IteratorProtocol {        associatedtype Element        mutating func next() -> Element?    }

其中，Element定义了我们逐个访问到的元素类型，而next方法则不断给我们返回下一个元素，所有元素都访问完了，next返回nil。另外，为什么我们要用mutating修饰next呢？大家先不用在意这个事情，在后面的内容里，就明白了。

用IteratorProtocol表示无穷序列

有了IteratorProtocol，怎么用呢？来看个最简单的例子：

struct Ones: IteratorProtocol {    mutating func next() -> Int? {        return 1    }}

这里，One表示一个包含无穷多个数字1的序列，为了逐个访问到这些数字，我们只要不断调用next就好了：

var ones = Ones()ones.next() // Optional(1)ones.next() // Optional(1)ones.next() // Optional(1)

虽然例子很简单，但有两点还是值得说一下：

第一，我们无需显式指定Element的类型，编译器可以从next()的签名中推导出来； 第二，这个例子要表达的重点是，我们无需关心ones这个序列的内部构成，只要知道调用next就可以得到下一个元素，或者得到nil，表示结束就好了；

当然，除了这种为了演示而编写的代码之外，我们也可以定义一些有用的Iterator，例如一个Fibonacci序列：

struct Fibonacci: IteratorProtocol {    private var state = (0,1)    mutating func next() -> Int? {        let nextNumber = state.0        self.state = (state.1,state.0 + state.1)        return nextNumber    }}

而用法，和ones如出一辙：

var fibs = Fibonacci()fibs.next() // Optional(0)fibs.next() // Optional(1)fibs.next() // Optional(1)fibs.next() // Optional(2)

看到这，你就明白为什么我们要让next是一个mutating方法了。为了遍历序列，我们几乎总是需要一些用于记录状态的属性，为了让next可以修改这些属性，必须用mutating来修饰它。

使用IteratorProtocol表达序列的局限性

但是，使用遵从IteratorProtocol的类型来表达序列，有一个让人困惑的地方。当我们要反复从头遍历一个序列的时候，该怎么办呢？显然，复制一个fibs并不行，它会从当前遍历的状态继续下去。我们唯一能做的，就是重新创建一个Fibonacci对象。

当然，由于Fibonacci是我们自己实现的，因此，我们了解这前前后后的所有细节。但是，当我们拿着Fibonacci给别人使用的时候，这种诡异的用法一定不会为你赢得同事的好评。

之所以会有这种问题，是因为我们借用了遍历的当前状态作为了序列的本身。ones也好，fibs也好，都如此。每一次调用next，我们用于记录当前遍历状态的值，恰好生成了我们期望的整个序列。

What's next?

为了解决这个问题，我们应该削弱遵循IteratorProtocol的类型表达的语意，让它在大多时候都只承载遍历的含义，而对于我们要表达的序列本身，再用一类约束来表达，这就是为什么Swift要提供protocol Sequence的原因。下一节，我们就来了解这个protocol。

总结

以上是内存溢出为你收集整理的Collections in Swift 4全部内容，希望文章能够帮你解决Collections in Swift 4所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。