[[181591]]

如果 Swift 里的 array 數(shù)組不能為空?

仔細(xì)想想: 如果 Swift 已經(jīng)設(shè)計(jì)了非空的數(shù)組了. 但這會讓人很煩對吧? 什么語言有非空的數(shù)組?

然而, Swift 比起 C 語言已經(jīng)修改了很多規(guī)則了. 例如, switch 里不需要 break 了, 甚至可以使用 fallthrough 來把幾個 case 連接起來. 沒有了 ++ 操作符, 它是那么的讓人迷惑, 多余, 并且沒了它語言會變得更好.

還有一點(diǎn) Swift 跟 C 不一樣, Swift 需要顯式地聲明可空性. Swift 讓你使用 Optional 類型, 向類型系統(tǒng)指定某個值是否可能有空. 你可以說你有一個 controller, 或者可能有一個 controller 也可能沒有. 類型系統(tǒng)可以在所有地方都檢查一遍, 保證這個值在被需要使用時不會為空.

<!--more-->

Doubly Empty

當(dāng) Optional 和 Array 產(chǎn)生交匯時, 你會有兩種方式去描述空值: nil 或者是空數(shù)組.

這可能會有點(diǎn)繞, 例如, 當(dāng)你檢查一個數(shù)組是否為 nil 或者為空數(shù)組的時候. 例如, 你想要更好地使用 Swift 里的 optional chaining 的時候, optionalArray?.isEmpty 卻返回了一個 Optional<Bool>, 一個本質(zhì)上很讓人迷惑的類型. 如果在 if 判斷句里使用了這一描述的話, 編譯器會拋出一個編譯錯誤, 因?yàn)檫@是一個 Optional 的布爾值.

optionalArray == [] 會被編譯, 但會在數(shù)組為 nil 的時候返回 false, 而這并不是我們想要的行為. 你可以有這么幾種方式達(dá)到目的, 但不多: 

if optionalArray == nil || optionalArray == [] { 
 
if let array = optionalArray, array.isEmpty { 
 
if (optionalArray ?? []).isEmpty { 
 
if optionalArray?.isEmpty != false { 
 
if optionalArray?.isEmpty ?? false {  

最簡單的方法是記住不要使用 Optional 的數(shù)組. 我一直嚴(yán)格遵守著這個規(guī)則, 保證不會把不同類型的"空值"混合到一起. 對于別的"可空"類型我也是這么做的 - 字典, 字符串, 布爾值和一些別的類型. 不得不去檢查兩種類型的控制檢查是我最不想做的事情.

遵守這個規(guī)則很容易, 例如說一個類里的屬性, 但不可能在所有情況下都遵守這個規(guī)則. 例如, 從一個 Optional 的實(shí)例那里獲取一個數(shù)組屬性就會成為一個 Optional 的數(shù)組.

let wheels = optionalCar?.wheels // 結(jié)果是 [Wheel]? 

從一個字典里面去獲取數(shù)組也是一樣.

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

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

我們剛擺脫了無法分辨 controller 和可空 controller 的困境. 獲得了簡化語句, 減少錯誤和可聲明的能力. 現(xiàn)在卻又遇上了這種窘境.

如果一個數(shù)組不能為空, 那 Optional 的數(shù)組就代表了空數(shù)組, 非 Optional 的數(shù)組則總會包含至少一個值. 就不可能同時出現(xiàn)兩種語義上的空值了, 而任何采用了別的語義的代碼都不會通過編譯.

Modeling

非空數(shù)組對于建立模型也很有用處. 告訴類型系統(tǒng)一個給定的數(shù)組永遠(yuǎn)不可能為空有時候很有用. 例如, 也許你的 User 類有許多個郵箱, 但如果 user 沒有郵箱的話則不應(yīng)該被驗(yàn)證. 可以讓類型系統(tǒng)接收這樣的描述是一件很棒的時期, 但現(xiàn)在我們做不到. 其他例子:

• 一個 Country 國家必須有至少一座 City 城市.
• 一張 Album 專輯必須有至少一首 Song 歌.
• 一棟 Building 樓必須有至少一層 Floor.

這樣的例子一大堆.

如果一個數(shù)組類型不能為空, 這些關(guān)系和約束全部都可以在類型系統(tǒng)里展現(xiàn)出來, 并且你不能刪掉數(shù)組里的***一個元素.

Expressions 語句表述

隨著 Optional 類型的出現(xiàn), 許多表述都被簡化 當(dāng)你知道一個類型永遠(yuǎn)不可能為空的時候, 你可以跳過空值檢查, 用一個更直觀的方式去操作它. 對于非空的數(shù)組也是一樣的. 現(xiàn)在, Collection 協(xié)議的方法, 例如 first, last, max 和 min 都會返回 Optional, 只是為了處理數(shù)組為空的情況.

有許多的情況下數(shù)組都不會為空, 但每當(dāng)我使用諸如 first 之類的方法的時候, 我還是不得不去做防御, 僅僅只是為了告訴類型系統(tǒng)它不為空.

如果數(shù)組不可能為空的話, 這些方法都可以返回一個非空值, 使用這些語句都會變得更容易. 空數(shù)組可以通過 optional chaining 來調(diào)用這些方法, 而返回值也會是 Optional.

Appending 插入

如果數(shù)組不可能為空, 那往非空數(shù)組里插入內(nèi)容就可以很正常地工作. 但往一個可空數(shù)組里插入值就會是一場災(zāi)難.

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

這很讓人心煩, 但好消息是, 在 Swift 3.1 里, 我們可以給特定類型的泛型類型添加 extension. 那么, 我們就可以往 Optional 的 Array類型添加方法(在這之前, 你只能給使用了遵守了協(xié)議的某個類型添加 extension)

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

現(xiàn)在我們可以像之前那樣暢通無阻的操作了.

Without Loss Of Generality

我們再進(jìn)一步, 如果數(shù)組的泛型參數(shù)包含了數(shù)組長度呢? 例如, 給 Array<of: 4, element: String> 插入一個值的時候就會返回一個Array<of: 5, element: String. 這個概念被稱為 dependent types, 并且在一些實(shí)驗(yàn)性的帶有更先進(jìn)的類型系統(tǒng)的語言里已經(jīng)實(shí)現(xiàn)了, 例如 Coq, Agda 和 Idris. Oisín 討論過如何在 Swift 里實(shí)現(xiàn)一樣的東西出來.

雖然這些東西非常好玩, 但也有一點(diǎn)不切實(shí)際. 你想想, 這意味著你不能在類里保存數(shù)組了, 除非你知道這個數(shù)組的長度永遠(yuǎn)不會被改變. 在很多情況下, 你不可能知道編譯時會有多少個對象從 API 和數(shù)據(jù)庫里被返回

簡單的鑒別 空/非空 有很明確的現(xiàn)實(shí)意義, 并且也會簡化 Swift 很多內(nèi)部運(yùn)作方式.

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 的嘗試. 但這也只是一個常規(guī)嘗試. 作為結(jié)尾, 我建立了一個非空數(shù)組類型. 你可以到這里看源碼, 運(yùn)作起來就像一個數(shù)組, 但不為空. 遵守 Sequence, Collection 協(xié)議并且有 == 和 != 方法.

由于 Swift 的類型系統(tǒng)有一部分我沒能完全理解, 但盡管如此, 你還是可以重寫協(xié)議(例如 Collection)里的方法(例如 first), 然后把Element? 修改了 Element, Swift 會在調(diào)用時爭產(chǎn)工作, 并且使用更加明確的類型, Element. 這意味著 NonEmptyArray 會在 first,last, max 和 min 里返回 non-optional, 雖然 Collection 里它們被定義為 Optional, repo 里的測試有斷言來判斷這個.

擁有一個絕對不為空的數(shù)組會有很多有趣的事情發(fā)生. 插入還好, 但刪除元素的方法會帶來更多問題. 我把這個方法標(biāo)記為 throws, 但經(jīng)過更多思考之后, 這也許不是一種正確地做法. 畢竟, Swift 原生的數(shù)組刪除元素時也會產(chǎn)生問題, 只是它比起 NonEmptyArray 可以一個以上的元素. Swift 的數(shù)組會在嘗試刪除空數(shù)組的元素時調(diào)用 fatalError, 所以也許這才是正確地做法.

我很期待可以把 NonEmptyArray 拆分成幾個提案, 看看失去 Swift 原生數(shù)組類型的語法糖是否值得, 去換取返回 non-optional 的方法.