Emptiness 空值语义

原文: Emptiness
作者: Soroush Khanlou
译者: kemchenj

如果 Swift 里的 array 数组不能为空?

仔细想想: 如果 Swift 已经设计了非空的数组了. 但这会让人很烦对吧? 什么语言有非空的数组?

然而,Swift 比起 C 语言已经修改了很多规则了. 例如,switch 里不需要 break 了,甚至可以使用 fallthrough 来把几个 case 连接起来. 没有了 ++ 操作符,它是那么的让人迷惑,多余,并且没了它语言会变得更好.

还有一点 Swift 跟 C 不一样,Swift 需要显式地声明可空性. Swift 让你使用 Optional 类型,向类型系统指定某个值是否可能有空. 你可以说你有一个 controller,或者可能有一个 controller 也可能没有. 类型系统可以在所有地方都检查一遍,保证这个值在被需要使用时不会为空.

<!--more-->

Doubly Empty

当 Optional 和 Array 产生交汇时,你会有两种方式去描述空值: nil 或者是空数组.

这可能会有点绕,例如,当你检查一个数组是否为 nil 或者为空数组的时候. 例如,你想要更好地使用 Swift 里的 optional chaining 的时候,optionalArray?.isEmpty 却返回了一个 Optional<Bool>,一个本质上很让人迷惑的类型. 如果在 if 判断句里使用了这一描述的话,编译器会抛出一个编译错误,因为这是一个 Optional 的布尔值.

optionalArray == [] 会被编译,但会在数组为 nil 的时候返回 false,而这并不是我们想要的行为. 你可以有这么几种方式达到目的,但不多:

if optionalArray == nil || optionalArray == [] {

if let array = optionalArray,array.isEmpty {

if (optionalArray ?? []).isEmpty {

if optionalArray?.isEmpty != false {

if optionalArray?.isEmpty ?? false {

最简单的方法是记住不要使用 Optional 的数组. 我一直严格遵守着这个规则,保证不会把不同类型的"空值"混合到一起. 对于别的"可空"类型我也是这么做的 - 字典,字符串,布尔值和一些别的类型. 不得不去检查两种类型的控制检查是我最不想做的事情.

遵守这个规则很容易,例如说一个类里的属性,但不可能在所有情况下都遵守这个规则. 例如,从一个 Optional 的实例那里获取一个数组属性就会成为一个 Optional 的数组.

let wheels = optionalCar?.wheels // 结果是 [Wheel]?

从一个字典里面去获取数组也是一样.

let wheels = dictionary["wheels"] as? [Wheel]

你不得不去在每一个语句后面都加上 ?? [].

我们刚摆脱了无法分辨 controller 和可空 controller 的困境. 获得了简化语句,减少错误和可声明的能力. 现在却又遇上了这种窘境.

如果一个数组不能为空,那 Optional 的数组就代表了空数组,非 Optional 的数组则总会包含至少一个值. 就不可能同时出现两种语义上的空值了,而任何采用了别的语义的代码都不会通过编译.

Modeling

非空数组对于建立模型也很有用处. 告诉类型系统一个给定的数组永远不可能为空有时候很有用. 例如,也许你的 User 类有许多个邮箱,但如果 user 没有邮箱的话则不应该被验证. 可以让类型系统接收这样的描述是一件很棒的时期,但现在我们做不到. 其他例子:

• 一个 Country 国家必须有至少一座 City 城市.

• 一张 Album 专辑必须有至少一首 Song 歌.

• 一栋 Building 楼必须有至少一层 Floor.

这样的例子一大堆.

如果一个数组类型不能为空,这些关系和约束全部都可以在类型系统里展现出来,并且你不能删掉数组里的最后一个元素.

Expressions 语句表述

随着 Optional 类型的出现,许多表述都被简化 当你知道一个类型永远不可能为空的时候,你可以跳过空值检查,用一个更直观的方式去操作它. 对于非空的数组也是一样的. 现在,Collection 协议的方法,例如 first,last,max 和 min 都会返回 Optional,只是为了处理数组为空的情况.

有许多的情况下数组都不会为空,但每当我使用诸如 first 之类的方法的时候,我还是不得不去做防御,仅仅只是为了告诉类型系统它不为空.

如果数组不可能为空的话,这些方法都可以返回一个非空值,使用这些语句都会变得更容易. 空数组可以通过 optional chaining 来调用这些方法,而返回值也会是 Optional.

Appending 插入

如果数组不可能为空,那往非空数组里插入内容就可以很正常地工作. 但往一个可空数组里插入值就会是一场灾难.

var emptiableArray = //...
emptiableArray == nil
    ? emptiableArray = [newItem]
    : emptiableArray?.append(newItem)

这很让人心烦,但好消息是,在 Swift 3.1 里,我们可以给特定类型的泛型类型添加 extension. 那么,我们就可以往 Optional 的 Array 类型添加方法(在这之前,你只能给使用了遵守了协议的某个类型添加 extension)

extension Optional<Array<Element>> {
    func append(_ element: Element) {
        switch self {
        case .some(array):
            array.append(element)
        case .none:
            self = [element]
        }
    }
}

现在我们可以像之前那样畅通无阻的操作了.

Without Loss Of Generality

我们再进一步,如果数组的泛型参数包含了数组长度呢? 例如,给 Array<of: 4,element: String> 插入一个值的时候就会返回一个 Array<of: 5,element: String. 这个概念被称为 dependent types,并且在一些实验性的带有更先进的类型系统的语言里已经实现了,例如 Coq,Agda 和 Idris. Oisín 讨论过如何在 Swift 里实现一样的东西出来.

虽然这些东西非常好玩,但也有一点不切实际. 你想想,这意味着你不能在类里保存数组了,除非你知道这个数组的长度永远不会被改变. 在很多情况下,你不可能知道编译时会有多少个对象从 API 和数据库里被返回

简单的鉴别 空/非空 有很明确的现实意义,并且也会简化 Swift 很多内部运作方式.

NonEmptyArray

This blog post is mostly a thought experiment. But it’s also a regular experiment. To that end,I built a non-empty array type. You can find it on GitHub here. It acts just like an array,but it isn’t emptiable. It conforms to Sequence,Collection,and has == and != methods.

这篇文章更像是一个 Idea 的尝试. 但这也只是一个常规尝试. 作为结尾,我建立了一个非空数组类型. 你可以到这里看源码,运作起来就像一个数组,但不为空. 遵守 Sequence,Collection 协议并且有 == 和 != 方法.

由于 Swift 的类型系统有一部分我没能完全理解,但尽管如此,你还是可以重写协议(例如 Collection)里的方法(例如 first),然后把 Element? 修改了 Element,Swift 会在调用时争产工作,并且使用更加明确的类型,Element. 这意味着 NonEmptyArray 会在 first,max 和 min 里返回 non-optional,虽然 Collection 里它们被定义为 Optional,repo 里的测试有断言来判断这个.

拥有一个绝对不为空的数组会有很多有趣的事情发生. 插入还好,但删除元素的方法会带来更多问题. 我把这个方法标记为 throws,但经过更多思考之后,这也许不是一种正确地做法. 毕竟,Swift 原生的数组删除元素时也会产生问题,只是它比起 NonEmptyArray 可以一个以上的元素. Swift 的数组会在尝试删除空数组的元素时调用 fatalError,所以也许这才是正确地做法.

我很期待可以把 NonEmptyArray 拆分成几个提案,看看失去 Swift 原生数组类型的语法糖是否值得,去换取返回 non-optional 的方法.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!