一篇文章幫你徹底了解 Swift 3.1 的新內(nèi)容

本文翻譯自 What’s New in Swift 3.1?


好消息好消息:Xcode 8.3 和 Swift 3.1 正式版的發(fā)布包含了等待已久的 Swift 包管理器 功能,以及對語言本身的改進。

如果你沒有一直密切關(guān)注 Swift Evolution Process ,那這篇文章就是為你準備的!

本文會強調(diào) Swift 3.1 中最重大的變動,這將對我們的代碼產(chǎn)生重大影響。來吧!:]

開始

Swift 3.1 和 Swift 3.0 是源碼兼容的,所以如果已經(jīng)使用 Edit\Convert\To Current Swift Syntax… 將項目遷移到了 Swift 3.0 的話,新功能將不會破壞我們的代碼。不過,蘋果在 Xcode 8.3 中已經(jīng)拋棄了對 Swift 2.3 的支持。所以如果還沒有從 Swift 2.3 遷移過來,現(xiàn)在要抓緊做了!

下面會有類似 [SE-0001] 的標簽鏈接。這些是 Swift Evolution 的提案號。我列出了每個提案的鏈接,以便查看某變動完整的細節(jié)信息。我建議在 playground 上試一下我們討論的功能,以便對于所有變動都有更好的理解。

所以,啟動 Xcode,選擇 File\New\Playground…. 選擇 iOS 平臺,隨便取個名字。一邊讀一邊在 playground 中嘗試每個功能。

注意:如果需要簡單回顧一下 Swift 3.0 重點,看看這篇文章 What’s New in Swift 3

語言改進

首先,看看這次發(fā)布中的語言改進,包括數(shù)字類型的可失敗初始化方法(failable initializers)、新的序列函數(shù)等等。

可失敗數(shù)值轉(zhuǎn)換初始化方法

Swift 3.1 為所有數(shù)字類型 (Int, Int8, Int16, Int32, Int64, UInt, UInt8, UInt16, UInt32, UInt64, Float, Float80, Double) 實現(xiàn)了可失敗初始化方法,要么完全成功、不損失精度,要么返回 nil [ SE-0080 ]。

這個功能很實用,例如,以安全、可還原(recoverable)的方式轉(zhuǎn)換來自外部的非確切類型數(shù)據(jù)。舉個實際的例子,我們可能會這樣處理一個學生的 JSON 數(shù)組:

class Student {
  let name: String
  let grade: Int
 
  init?(json: [String: Any]) {
    guard let name = json["name"] as? String,
          let gradeString = json["grade"] as? String,
          let gradeDouble = Double(gradeString),
          let grade = Int(exactly: gradeDouble)  // <-- 這里是 3.1 的功能
    else {
        return nil
    }
    self.name = name
    self.grade = grade
  }
}
 
func makeStudents(with data: Data) -> [Student] {
  guard let json = try? JSONSerialization.jsonObject(with: data, options: .allowFragments),
        let jsonArray = json as? [[String: Any]] else {
    return []
  }
  return jsonArray.flatMap(Student.init)
}
 
let rawStudents = "[{\"name\":\"Ray\", \"grade\":\"5.0\"}, {\"name\":\"Matt\", \"grade\":\"6\"},
                    {\"name\":\"Chris\", \"grade\":\"6.33\"}, {\"name\":\"Cosmin\", \"grade\":\"7\"}, 
                    {\"name\":\"Steven\", \"grade\":\"7.5\"}]"
let data = rawStudents.data(using: .utf8)!
let students = makeStudents(with: data)
dump(students) // [(name: "Ray", grade: 5), (name: "Matt", grade: 6), (name: "Cosmin", grade: 7)]

我們在 Student 類的指定可失敗初始化方法中用可失敗構(gòu)造器將 grade 屬性從 Double 轉(zhuǎn)換為 Int,就像這樣:

let grade = Int(exactly: gradeDouble)

如果 gradeDouble 是小數(shù),例如 6.33,就會失敗。如果可以用 Int 來表示,例如 6.0,就會成功。

注意:還有一種可替代的設計是使用拋出錯誤的初始化方法而不是可失敗的。社區(qū)選擇了可失敗的,因為它更好、更符合工程學設計。

新的序列函數(shù)

Swift 3.1 為標準庫的 Sequence 協(xié)議增加了兩個新函數(shù),用于數(shù)據(jù)過濾:prefix(while:) 和 drop(while:) [ SE-0045 ]。

考慮斐波那契無限數(shù)列:

let fibonacci = sequence(state: (0, 1)) {
  (state: inout (Int, Int)) -> Int? in
  defer {state = (state.1, state.0 + state.1)}
  return state.0
}

在 Swift 3.0 中,我們只需指定迭代次數(shù)(iteration count)即可遍歷斐波那契數(shù)列:

// Swift 3.0
for number in fibonacci.prefix(10) {
  print(number)  // 0 1 1 2 3 5 8 13 21 34
}

Swift 3.1 允許我們使用 prefix(while:) 和 drop(while:) 來獲取位于序列兩個給定值之間所有的元素,像這樣:

// Swift 3.1
let interval = fibonacci.prefix(while: {$0 < 1000}).drop(while: {$0 < 100})
for element in interval {
  print(element) // 144 233 377 610 987
}

prefix(while:) 返回滿足某 predicate 的最長子序列。從序列的開頭開始,并且在第一個從給定閉包中返回 false 的元素處停下。

drop(while:) 做相反的操作:從第一個在閉包中返回 false 的元素開始,直到序列的結(jié)束,返回此子序列。

注意:這種情況下可以使用尾隨閉包(trailing closure):
let interval = fibonacci.prefix{$0 < 1000}.drop{$0 < 100}

Concrete Constrained Extensions

Swift 3.1 允許我們擴展具有 concrete type constraint 的泛型。之前不能擴展這樣的類型,因為約束必須是一個協(xié)議??匆粋€例子。

例如,Ruby On Rails 提供了一個非常實用的方法 isBlank 用于檢查用戶輸入。在 Swift 3.0 中我們會將其實現(xiàn)為 String 擴展中的計算屬性

// Swift 3.0
extension String {
  var isBlank: Bool {
    return trimmingCharacters(in: .whitespaces).isEmpty
  }
}
 
let abc = " "
let def = "x"
 
abc.isBlank // true
def.isBlank // false

如果想要 string 可選值 也能用 isBlank 計算屬性,在 Swift 3.0 中要這么做:

// Swift 3.0
protocol StringProvider {
  var string: String {get}
}
 
extension String: StringProvider {
  var string: String {
    return self
  }
}
 
extension Optional where Wrapped: StringProvider {
  var isBlank: Bool {
    return self?.string.isBlank ?? true
  }
}
 
let foo: String? = nil
let bar: String? = "  "
let baz: String? = "x"
 
foo.isBlank // true
bar.isBlank // true
baz.isBlank // false

我們創(chuàng)建了一個 StringProvider 協(xié)議供 String 采用。當拆包類型是 StringProvider 的時候使用它擴展 Optional,添加 isBlank 方法。

Swift 3.1 可以不用這樣的協(xié)議來擴展 concrete type:

// Swift 3.1
extension Optional where Wrapped == String {
  var isBlank: Bool {
    return self?.isBlank ?? true
  }
}

與之前相同的功能,但是代碼更少!

泛型嵌套

Swift 3.1 讓我們可以混合使用泛型和類型嵌套。練習一下,看看這個(不是很難的)例子。如果某個 raywenderlich.com 的團隊領(lǐng)導想要在博客上發(fā)一篇文章,他會找專門的開發(fā)者團隊來處理這個問題,以保證文章的質(zhì)量:

class Team<T> {
  enum TeamType {
    case swift
    case iOS
    case macOS
  }
 
  class BlogPost<T> {
    enum BlogPostType {
      case tutorial
      case article
    }
 
    let title: T
    let type: BlogPostType
    let category: TeamType
    let publishDate: Date
 
    init(title: T, type: BlogPostType, category: TeamType, publishDate: Date) {
      self.title = title
      self.type = type
      self.category = category
      self.publishDate = publishDate
    }
  }
 
  let type: TeamType
  let author: T
  let teamLead: T
  let blogPost: BlogPost<T>
 
  init(type: TeamType, author: T, teamLead: T, blogPost: BlogPost<T>) {
    self.type = type
    self.author = author
    self.teamLead = teamLead
    self.blogPost = blogPost
  }
}

我們把內(nèi)部類 BlogPost 嵌套在對應的外部類 Team 中,這兩個類都是泛型。目前團隊在尋找已發(fā)布的教程和文章時需要這樣做:

Team(type: .swift, author: "Cosmin Pup?z?", teamLead: "Ray Fix", 
     blogPost: Team.BlogPost(title: "Pattern Matching", type: .tutorial, 
     category: .swift, publishDate: Date()))
 
Team(type: .swift, author: "Cosmin Pup?z?", teamLead: "Ray Fix", 
     blogPost: Team.BlogPost(title: "What's New in Swift 3.1?", type: .article, 
     category: .swift, publishDate: Date()))

但實際上可以簡化這里的代碼。如果嵌套的內(nèi)部類型用了外部的泛型,它就默認繼承了父類的類型。因此我們不需要聲明,只要這樣寫就可以了:

class Team<T> {
  // 本來的代碼
 
  class BlogPost {
    // 本來的代碼
  }  
 
  // 本來的代碼
  let blogPost: BlogPost
 
  init(type: TeamType, author: T, teamLead: T, blogPost: BlogPost) {
    // 本來的代碼   
  }
}

注意:如果想學習 Swift 中的泛型,讀一讀這篇最近更新的教程 getting started with Swift generics 。

Swift 版本可用性

我們可以使用 Swift ?版本的 #if swift(>= N) 靜態(tài)構(gòu)造器,像這樣:

// Swift 3.0
#if swift(>=3.1)
  func intVersion(number: Double) -> Int? {
    return Int(exactly: number)
  }
#elseif swift(>=3.0)
  func intVersion(number: Double) -> Int {
    return Int(number)
  }
#endif

然而在使用 Swift 標準庫這樣的東西時,這種方法有一個很大的缺點。它需要為每個舊語言版本編譯標準庫。因為如果要使用 Swift 3.0 的行為,則需要使用針對該版本編譯的標準庫。如果使用 3.1 版本的標準庫,就根本沒有正確的代碼。

所以,Swift 3.1 擴展了 @available 屬性 [ SE-0141 ]:

// Swift 3.1
 
@available(swift 3.1)
func intVersion(number: Double) -> Int? {
  return Int(exactly: number)
}
 
@available(swift, introduced: 3.0, obsoleted: 3.1)
func intVersion(number: Double) -> Int {
  return Int(number)
}

這個新功能與 intVersion 方法相同。但是,它只允許像標準庫這樣的庫被編譯一次。編譯器隨后只要選擇與對應版本兼容的功能即可。

注意:如果想學習 Swift 的 availability attributes,看看這篇教程 availability attributes in Swift。

將非逃逸閉包轉(zhuǎn)換為逃逸閉包

Swift 3.0 把函數(shù)的閉包參數(shù)改為默認非逃逸 [SE-0103]。但是,該提案當時并沒有被完全實現(xiàn)。在 Swift 3.1 中,可以使用新的輔助函數(shù) withoutActuallyEscaping() 臨時轉(zhuǎn)換非逃逸閉包。

為什么要這么做?雖然可能永遠都不會用到,但還是考慮一下提案提到的這個例子。

func perform(_ f: () -> Void, simultaneouslyWith g: () -> Void,
             on queue: DispatchQueue) {
  withoutActuallyEscaping(f) { escapableF in     // 1
    withoutActuallyEscaping(g) { escapableG in
      queue.async(execute: escapableF)           // 2
      queue.async(execute: escapableG)     
 
      queue.sync(flags: .barrier) {}             // 3
    }                                            // 4
  }
}

此函數(shù)同時運行兩個閉包,然后在兩個都完成之后返回。

  1. f 和 g 一開始是非逃逸的,并被轉(zhuǎn)換為 escapableF 和 escapableG。
  2. 調(diào)用 async(execute:) 需要逃逸閉包。很幸運,我們已經(jīng)搞定了。
  3. 運行 sync(flags: .barrier),以確保 async(execute:) 被全部完成了、之后不會再調(diào)用閉包。
  4. Scope 限制了 escapableF 和 escapableG 的使用。

如果不臨時轉(zhuǎn)換為逃逸閉包,就會是一個 bug。標準庫未來應該能夠檢測到這種錯誤的調(diào)用。

Swift 包管理器的更新

啊啊啊啊,期待已久的 Swift 包管理器終于更新了!

Editable Packages

Swift 3.1 在 Swift 包管理器 中新增了 Editable Packages 概念 [ SE-0082 ]。

swift package edit 命令可以將現(xiàn)有包轉(zhuǎn)換為可編輯的??删庉嫷陌鼘鎿Q dependency graph 中的規(guī)范包。使用 —end-edit 命令將包管理器還原回規(guī)范解析的包。

Version Pinning

Swift 3.1 在特定版本的 Swift 包管理器 中新增了 version pinning 概念 [ SE-0145 ]。 pin 命令會像這樣固定一個或多個依賴:

$ swift package pin --all      // pin 所有依賴
$ swift package pin Foo        // 把 Foo pin 在當前解析版本 
$ swift package pin Foo --version 1.2.3  // 把 Foo pin 在 1.2.3

使用 unpin 命令恢復到以前的包版本:

$ swift package unpin —all
$ swift package unpin Foo

包管理器在 Package.pins 中存儲每個包的活躍版本 pin 信息。如果文件不存在,包管理器則會按照包 manifest 中指定的要求自動創(chuàng)建該文件,這是 automatic pinning 過程的一部分。

其它

swift package reset 命令將包重置為干凈狀態(tài),不會檢出當前的依賴關(guān)系或 build artifact。

還有,使用 swift test --parallel 命令并行執(zhí)行測試。

雜項

Swift 3.1 還有一些并不屬于以上某個分類的改動:

多重返回函數(shù)

返回兩次的 C 函數(shù)(如 vfork 和 setjmp )將無法繼續(xù)使用。它們以可笑的方式改變了程序的控制流程。所以 Swift 社區(qū)已經(jīng)決定禁止使用它們,現(xiàn)在直接會導致編譯時錯誤。

禁用 Auto-Linking

Swift 包管理器 禁用了 C 語言 target module mapsauto-linking 功能:

// Swift 3.0
module MyCLib {
    header “foo.h"
    link “MyCLib"
    export *
}
 
// Swift 3.1
module MyCLib {
    header “foo.h”
    export *
}

下一步?

Swift 3.1 優(yōu)化了一些 Swift 3.0 的功能,為將在今年推出的 Swift 4.0 中捆綁的重大改動做準備。包括對泛型的巨大改進,正則表達式,更符合工程學的字符串設計等等。

如果你喜歡挑戰(zhàn),可以看看 Swift standard library diffs ,或者查看官方的 Swift CHANGELOG ,可以在其中閱讀有關(guān)所有改動的更多信息?;蛘呖梢杂盟鼇砹私?Swift 4.0 中的內(nèi)容!

如果好奇 Swift 4 及更高版本中的改動,可以去 Swift Evolution proposals ,可以看到現(xiàn)在提案的內(nèi)容。如果真的很熱愛 Swift,為什么不就目前的提案提出意見,甚至自己提出提案呢?:]

所以你現(xiàn)在喜不喜歡 Swift 3.1?歡迎在下方評論!

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

  • 本文來自簡書,原文地址:http://m.itdecent.cn/p/bb0bd1881a35 好消息好消息:...
    XLsn0w閱讀 379評論 0 0
  • 開始Swift 3.1 和 Swift 3.0 是源碼兼容的,所以如果已經(jīng)使用 Edit\Convert\To C...
    DY_108閱讀 324評論 0 0
  • 本文翻譯自raywenderlich.com中的文章《What’s New in Swift 4?》,由于本人...
    周杰木有倫閱讀 1,213評論 0 4
  • 說起夫妻相處,聽過很多,也看過很多,覺得都有道理。可是遇到實際問題,落實到實際生活中,卻不怎么容易。 ...
    藍天碧海123456閱讀 242評論 1 1
  • 從上班開始,便和辦公桌結(jié)下了不解之緣。 在辦公室里,有我的一張辦公桌。棕色的,長方形。和六個同事或者十二個同事處于...
    一品歲月閱讀 351評論 0 2

友情鏈接更多精彩內(nèi)容