翻译来源
Swift 4.2 improves Hashable with a new Hasher struct
Swift 4.2对 Hashable 协议做了优化，使其 更快、更简单、更安全。
Hashable 是Swift最重要的协议，但是我们通常都注意不到这个协议。不是因为我们用不到，而是系统已经帮我们创建并实现了这个协议。
在Swift4.1之前，Hashable实现起来是比较复杂的，需要我们自己去计算一个 hashValue,如下
struct Jedi: Hashable {
var name: String
var darkSideUsage: Int
var hashValue: Int {
return name.hashValue ^ darkSideUsage.hashValue &* 16777619
}
}
在4.1中，做到了简化，如下
struct Jedi: Hashable {
var name: String
var darkSideUsage: Int
}
虽然在4.1中做了简化，但是当我们需要自己实现的时候
例如，我们有很多属性，但是我们确定只需要一个属性就可以确定他的值，这个时候我们还是需要实现 hashValue
Swift 4.2改善了这个情况，引入了一个新的哈希结构体，它提供一个随机的、通用的哈希函数，来使这些更加简单。SE-0206: Hashable Enhancements
如果自己生成hashes,代码变得简洁许多
struct Jedi: Hashable {
var name: String
var darkSideUsage: Int
func hash(into hasher: inout Hasher) {
hasher.combine(name)
hasher.combine(darkSideUsage)
}
}
我们也可以使用 Hasher作为一个单独的哈希构造器来使用,独立的构造器最后要调用finalize()函数,例如：
let obiwan = Jedi(name: "Obi-wan Kenobi", darkSideUsage: 0)
let anakin = Jedi(name: "Anakin Skywalker", darkSideUsage: 90)
var hasher = Hasher()
hasher.combine(obiwan)
hasher.combine(anakin)
let hash = hasher.finalize()
这一切看起来没有什么不同，到最后我们都获取到了一个integer数值。有一个最大的不同就是，现在我们生成的 哈希值 是随机的，这就意味着给定对象的哈希值将在程序运行之间发生变化。
随机的哈希值是一个重要的特性，因为可预测的哈希值，让攻击者有可乘之机。事实上，有一款叫做 hash flooding的软件就可以实现攻击，如果我提前知道你的哈希算法，我可以很容易地生成许多具有相同哈希的不同对象。例如哈希算法是这样的
struct Jedi: Hashable {
var name: String
var darkSideUsage: Int
var hashValue: Int {
return name.hashValue &* 16777619
}
}
他们可以使用相同的名称和不同的darkSideUsage属性生成任意数量的绝地物体。这些对象足够独特，可以多次添加到相同的集或字典中，但也足够相似，可以生成相同的散列。
for _ in 1...100 {
set.insert(Jedi(name: "Obi-wan Kenobi", darkSideUsage: Int(arc4random_uniform(UInt32.max))))
}
我们创建了100个名为Obi-wan Kenobi的Jedi，每一个都有不同的darkSideUsage属性。
关于集合和字典的是如何工作的是很重要的。有一个误解，就是哈希值必须是唯一的，但是并非如此，如果是唯一的会更好，但是字典和集合完全可以保存具有相同哈希值的不同对象。
在上面的例子中，我们创建了100个Jedi具有相同哈希值的Jedi对象，我们做一个测试，从这个100个对象中取出我需要的对象，用时0.002s,但是如果10000个对象呢。
你可能觉得需要100*0.002 = 0.2s，但是我们却用了1.92s,如果是30000个对象，用时21.48s。
常规的字典和集合的时间复杂度是0(1)，但是我们现在的是0(n^2)。就是因为我们的对象的哈希值相同造成的哈希碰撞。
假设现在有人创建100000这种伪相同的对象，这就可能直接导致程序崩溃。但是4.2解决了这个问题，它使用了一个名为 SipHash 的伪随机函数，该函数是专门设计的，因此攻击者无法再提前预测给定对象的哈希值。
现在你知道为什么 哈希洪水攻击为什么这么危险了吧。我们再举一个更真实的例子。
忙碌一天了，Jedi想要回家了，我们更新一下Jedi的结构，为他添加地址
struct Jedi: Hashable {
var name: String
var darkSideUsage: Int
var address1: String
var address2: String
var city: String
var state: String
var postCode: String
var country: String
var hashValue: Int {
return name.hashValue ^
address1.hashValue ^
address2.hashValue ^
city.hashValue ^
state.hashValue ^
postCode.hashValue ^
country.hashValue &* 16777619
}
}
Jedi用到了姓名和每一个地址生成哈希值。但是，这些算法还是可以被攻击，我们还可以创建具有相同哈希值的不同对象，如下：
let test1 = Jedi(name: "test1", darkSideUsage: 0, address1: "1", address2: "2", city: "3", state: "4", postCode: "5", country: "6")
let test2 = Jedi(name: "test1", darkSideUsage: 0, address1: "2", address2: "1", city: "3", state: "4", postCode: "5", country: "6")
let test3 = Jedi(name: "test1", darkSideUsage: 0, address1: "3", address2: "2", city: "1", state: "4", postCode: "5", country: "6")
第一个对象使用1，2，3作为他的地址，第二个使用2，1，3作为地址，第三个使用3，2，1作为地址。因为实际存储的数据是相同的，哈希值也将是相同的——它们出现在不同的属性中并不重要，因为 a ^ b ^ c 产生与 c ^ a ^ b 相同的结果。
通过七个字符串属性，我们的属性有超过 5000 种这样的组合。 如果你为你的散列使用八个属性，则有超过 40,000 个，如果你使用十个，你将拥有超过 350 万个——这对攻击者来说都是微不足道的，因为它只是在不同的地方使用相同的字符串。
新的Hasher通过维护哈希状态来避免这种情况。 这就是使用 combine() 方法生成哈希的原因：每次将新属性添加到哈希中时，它都会与之前的状态相结合，确保添加的顺序很重要。
因此，我们可以重写我们的散列代码以使用新的 Swift 4.2 hash(into:)方法，如下所示：
func hash(into hasher: inout Hasher) {
hasher.combine(name)
hasher.combine(address1)
hasher.combine(address2)
hasher.combine(city)
hasher.combine(state)
hasher.combine(postCode)
hasher.combine(country)
}
现在Jedi都会生成完全不同的哈希值，即使他们存储的字符串是相同的。
