Swift 5.3 又更新了什麼新奇爽快的語法？

時間 2020-07-22

標籤 swift 5.3 更新什麼新奇語法欄目 Swift 简体版

原文原文鏈接

Swift 發展里程碑

Swift 在 WWDC14 正式發佈到 2019，通過 5 年的不斷迭代，這其中經歷了標準庫變更，語法的增減。首先使用 Swift 做爲開發語言的開發者們都苦不堪言，戲稱《Swift 從入門到重學》，幾乎每年 Swift 都會迎來比較大的改動，甚至 API 都發生了變化。 git

WWDC 19 蘋果發佈了 Swift 5.0，蘋果終於宣佈 Swift 的 ABI 穩定。這標誌着 Swift 這門語言已經趨於穩定，在 2019 至 2020 的迭代中，Swift 5.2 也作到了模塊穩定，以前的大修大改已經不會在出現了。github

有意思的是，在 WWDC16 中有一頁 PPT 寫下了 Goals for Swift 3：express

Develop an open community

Portability to new platforms

Get the fundamentals right

Optimize for awesomenss

現在已經 2020 年，再回頭看這些目標，Swift 5.3 幾乎徹底實現了。Swift 可謂一直不忘初心，朝着認爲正確的方向不斷的努力。編程

（ WWDC 2020精彩內容思否專欄：https://segmentfault.com/blog... swift

本篇內容來自於阿里巴巴淘系技術部，無線開發工程師星志。
更多精彩內容可關注【淘系技術】公衆號。）segmentfault

語法的不斷成熟

每一年 WWDC 比較期待的一個點就是看看 Swift 又加了一些什麼新奇爽快的語法。我先列舉一下 Swift 5.3 新增的語法:安全

[SE-0249] KeyPath as Function
[SE-0279] Multiple trailing closure
[SE-0281] Type-based program entry point (@main))
[SE-0266] Synthesized comparable conformation for enum types
[SE-0269] Increased availability of implicit self in closure
[SE-0276] Multi-pattern catch clauses
[SE-0280] Enum cases as protocol witnesses
[SE-0267] Where clauses on contextually generic declarations
[SE-0270] Collection operations on noncontiguous elements
[SE-0264] Standard library preview package
[SE-0253] Callable values of user-defined nominal types
[SE-0263] String initializer with access to uninitialized storage

上面列舉的 12 個語法改動，有興趣的同窗能夠到 swift-evolution 去查看詳細的內容。其中比較有意思的幾個改動就是 [SE-279]，[SE-281]和[SE-0269]，咱們來細細評味一下。閉包

Design for SwiftUI

[SE-279] Multiple trailing closure 多重尾閉包這個新特性算是一個很是大的改動。這個特性的出現影響了 Swift 很是重要的地方，API 設計。先來幾個官方的例子：架構

上面的代碼中 2 的狀況是常常出現的，尾閉包的含義就不夠明確，之前最佳的方式應該爲 3，可是兩個閉包被套在一個小括號裏，使得括號多重嵌套，可讀性降低。爲了解決這個問題，蘋果使用了第 4 中方法--多重尾閉包。能夠從代碼看出可讀性獲得了很大的提高。app

這一看似優雅的設計其實引入了不少語言的複雜度，有了這個特性你甚至能夠寫出相似下面的代碼，看上去就像是創造了一個 if-else 語句，但其實它是一個函數。

這就對 SDK 的開發者提出了更高的要求，須要當心的使用這個特性來設計 API，防止這個特性被濫用致使代碼的可讀性降低，甚至形成歧義。蘋果在 WWDC20 中也強調了這一點。

還有兩個特性其實很簡單，[SE-0281] 是 @main 來標記程序入口，[SE-0269] 是讓開發者在特定的狀況下不須要再寫多餘的 self.。

蘋果推出了這幾個語言特性，就是爲了讓戰略性的項目 SwiftUI 的 API 更加簡潔明瞭。能夠看下面的例子:

蘋果也不是第一次爲了 SwiftUI 改 Swift 的語法，[SE-0255] Implicit returns from single-expression functions 就是爲了讓 SwiftUI 的 body 不用寫 return，強化 DSL 風格。

蘋果爲了 SwiftUI，推出了 functionBuilder 來實現 DSL 形式的代碼；爲了 SwiftUI，推出了許多讓它更漂亮的語法特性；爲了 SwiftUI，不惜爲語言引入更多的複雜度。

下限低，上限高

Swift 的最初的設計方向就致使了它是一門下限很低上限很高，入門容易精通難，使用容易設計難的語言。它一系列的語法糖和語法設計，包括類型推斷系統，都是讓它成爲十分親民的語言，而它的一系列語法特性，讓它在設計 API、SDK實現的時候其複雜程度也不亞於其餘語言。

Swift is a general-purpose, multi-paradigm, compiled programming language developed by Apple Inc. for iOS, iPadOS, macOS, watchOS, tvOS, and Linux.
---- Wikipedia

維基百科的後半部分可能有些侷限了，可是前半部分說明了它是一門多編程範式的語言，Swift 能夠支持面向對象編程(OOP)，面向協議編程(OPP)，聲明式編程(DP)，函數式編程(FP)，泛型編程(GP)。

Objective-C 已經發展了這麼多年，如此成熟，爲何如今蘋果要開始拋開它？Objective-C 原本就是生於一個面向對象編程範式起飛的一年，與 C++ 同樣爲了拓展 C 命令式編程範式而誕生的語言。當時 C 語言雖然也能夠實現 OOP，可是語法設計成爲了限制。在當代計算機編程語言研究演進下，出現了不少編程範式的新理論，如函數式編程，元編程等等，一樣 OC 能夠經過它的方式來實現，可是語言的冗雜和 OOP 的設計已經不能更好的表達這些概念，就猶如純 C 來表達OOP 同樣。

蘋果推出 Swift 就是爲了擺脫 OC 的束縛，讓它能更好的踐行現代的編程理論，因此纔會誕生出 SwiftUI，纔會有 Combine、map/filter/reduce 等這些庫和 API。類型推斷和元編程的理論也讓 Swift 在保留強類型的環境下還能保持如此簡潔優雅，可讀性強的代碼。而這些是 OC 沒法作到的。嘗試使用 OC 對這些現代概念作表達的 SDK 都會顯得十分冗雜。

如今 Swift 語法已經不會再大變，有如此現代、安全、穩定、富有想象力的語言，有什麼理由不真香呢？

土壤已經肥沃

咱們先經過下面的腦圖感覺一下 Swift 更迭到 5.3 已經取得的成就。

如今 Swift 生態環境已經自成一派，有一套完整的工具鏈保證開發，有更獨立的標準庫讓它能夠自由遷移，包管理讓豐富了它的 SDK，同時還具備 Native 語言的各類優點。在這麼多年的發展中，它的能力已經觸及到了 AI、Server、Mobile Device、FaaS，強大的標準庫讓它甚至能夠當腳本語言使用。

Swift 現在已經再也不孤立無援，開源讓 Swift 變得生機勃勃，合理優雅的設計和開放的態度讓全球的開發者們都在不斷的完善它。

在 Swift 的大生態中，包管理工具是最值得一說的。一門語言它的能力，取決於它是否有強有力的 SDK，還有就是獲取他們的途徑。基礎的 Swift 的能力都由工具鏈和標準庫提供，而強有力的 SDK 最好的方式就是經過包管理工具快速獲取。Swift Package Manager 就是 Swift 的軍械庫。

Swift Package Manager

看一下 Swift Package Manager(SPM) 的發展歷程，SPM 從 Swift 3.0 時就發佈，當時只支持 Git 遠端倉庫，支持支源碼發佈。WWDC 19，Xcode 引入了一個新的架構 XCFramework，一個旨在能打包多個平臺 framework 的文件結構。WWDC20 SPM 宣佈正式支持發佈二進制 framework。

WWDC20 SPM 走出的這一步標誌着功能的完善。爲何這麼說，由於在 iOS 屆，解決了 Xcode 無包管理工具難題，讓衆多優秀的開源庫能被快速獲取的包管理工具 -- Cocoapods。在 SPM 出現以前，Cocoapods 的功能已經很是完善，戰勝了當時另外的一款包管理工具 Carthage。

Cocoapods 做爲基於 Xcode 開發的第三方包管理工具，經過修改 Xcode 的工程信息來實現處理各個包的依賴問題。它支持依賴的二進制分發、源代碼分發，基於 framework 良好的資源管理。如今許多公司的大型 App 也是用 Cocoapods 作模塊化組件分離，經過二進制依賴的方式來提升打包速度。

然而比較惋惜的是它工做流是脫離 Xcode 的，Podfile 更新等操做都是在工程以外。語言使用的是 Ruby，雖然使用了一些操做使 Podfile 變成了 DSL，可是對於開發者而言是有必定門檻的，特別是須要編輯發佈 SDK 所使用的 podspec 時，對照文檔，無代碼提示的編寫讓寫正確配置文件都成了難事。Cocoapods 還不得不設計出 podspec lint 來幫組開發者確認這個事情。

對於 Swift PM 這個親兒子而言，就不存在這個問題，SPM 已經深刻的集成到了 Xcode 中，全部的操做均可以利用 Xcode 完成。在編寫 Swift Package 時，Xcode 如今已經具有將 Package.swift 做爲工程項目打開，而且如今工程模板中已經包含了 Swift Package。強大的 Xcode 自動補全讓編寫 Package.swift 再也不是一件難事。若是脫離 Xcode，利用 swift-lsp 結合如今熱門的文本編輯器，如 VSCode 等均可以實現相應的功能。SPM 如今已是獨立於 Xcode 的存在，能夠爲 Swift 提供強有力的支持。

SPM 在功能層面已經不遜於 Cocoapods，在 WWDC20 時，SPM 已經支持以二進制庫形式分發 Package，SPM 也能夠管理包中的資源和本地化，基本的能力已經與 Cocoapods 差別不大，然而最關鍵的是，SPM 是純 Swift ，開源，還有蘋果官方支持的包管理工具。

新瓶釀酒酒更香

國外的很多 APP 已經遷移到了 Swift；三方開源庫如 AFNetworking 已經用 Swift 重寫爲 Alamofire，Lottie 已經徹底被 Swift 重寫替代。蘋果也推出了許多 Swift Only 的庫。蘋果也在利用 Swift 爲 UIKit，GCD 等基礎庫不斷提供更具備表現力的 API。

Uber 完成了遷移，收穫了 Swift 極強的穩定性。Alamofire，SnapKit 用 Swift 重寫，得到了更加具備表現力的 API，開發者更容易接受且喜好。 Reactive 系列的編程風格在 Swift 上大放異彩。