Emptiness 空值语义

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

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

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

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

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

Doubly Empty

OptionalArray 产生交汇时, 你会有两种方式去描述空值: 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, maxmin 都会返回 Optional, 只是为了处理数组为空的情况.

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

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

Appending 插入

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

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

这很让人心烦, 但好消息是, 在 Swift 3.1 里, 我们可以给特定类型的泛型类型添加 extension. 那么, 我们就可以往 OptionalArray 类型添加方法(在这之前, 你只能给使用了遵守了协议的某个类型添加 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, AgdaIdris. 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, last, maxmin 里返回 non-optional, 虽然 Collection 里它们被定义为 Optional, repo 里的测试有断言来判断这个.

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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 196,099评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,473评论 2 373
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 143,229评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,570评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,427评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,335评论 1 273
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,737评论 3 386
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,392评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,693评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,730评论 2 312
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,512评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,349评论 3 314
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,750评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,017评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,290评论 1 251
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,706评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,904评论 2 335

推荐阅读更多精彩内容