Swift 5.3 新特性精講(1)：多尾閉包，一個不能自洽的特性

也許是做爲爭議最大的特性之一，多尾閉包這個特性被歸入 Swift 5.3。爲何會有那麼大的爭議呢？聽我慢慢道來。

單尾閉包

調用單個尾閉包的函數時有一種精簡的寫法：省去這個尾閉包的標籤、而且把閉包放在圓括號外面。如下兩種寫法等價。

UIView.animate(withDuration: 0.25, animations: {
  // animation code
})

// 單個尾閉包的精簡寫法
UIView.animate(withDuration: 0.25) {
  // animation code
}
複製代碼

然而，Swift 5.3 以前若是有多個尾閉包的話，也只有最後一個閉包能被寫成精簡形式，這種寫法蘋果以爲不是太好看，由於一個閉包在圓括號內，另外一個在外面。所以蘋果的推薦作法是，碰到這種須要仍是換成傳統的寫法吧。

// 寫法 1（單尾閉包精簡寫法）
UIView.animate(withDuration: 0.25, animations: {
  // animation code
}) { completed in
  // completion code
}

// 寫法 2（傳統寫法）
UIView.animate(withDuration: 0.25, animations: {
  // animation code
}, completion: { completed in
  // completion code
})
複製代碼

正因如此，給此次的爭議埋下了隱患，由於這只是建議，並無什麼強制的措施，甚至編譯器也不會給警告的。事實上，在 Xcode 12 以前，直接在最後一個閉包的代碼提示上按回車，代碼會被自動切換成第一種的形式。所以，第一種寫法有很是多的存量代碼。

多尾閉包

Swift 5.3 的時候，蘋果「從新思考」了多尾閉包的場景，它給出了一種新的調用寫法：

// 寫法 3（多尾閉包精簡寫法）
UIView.animate(withDuration: 0.25) {
  // animation code
} completion: { completed in
  // completion code
}
複製代碼

這種新的寫法，把最後的連續幾個閉包參數都算做是尾閉包了，這些閉包如今均可以放在圓括號外面了，顯得清爽了不少。

可是，這些尾閉包中的第一個閉包被強制省略，能夠看到這裏的 animations標籤被強制省略，注意是強制哦！加上了是編譯不過的。蘋果給出的解釋是：若是容許第一個尾閉包加上標籤，那麼開發者須要考慮是加好仍是不加好，你看這會致使代碼風格不一致，那麼幹脆禁了吧。

呵呵。一個多尾閉包的狀況如今都有三種合法的寫法了，你不在考慮增長第三種寫法的時候考慮一下是否是會讓開發者多一種選擇的爲難，卻貼心的考慮到了「我就是要」增長的第三種寫法裏面讓開發者少一點爲難，謝謝你啊。

這個多尾閉包還有個特性是，除了第一個尾閉包不配擁有姓名以外，其他的尾閉包都得有姓名（標籤）。因此搞笑的是：一樣做爲合法的寫法，第一種寫法省略了completion標籤，而第三種寫法省略了animations標籤。這不是找罵麼，對於 API 的設計者來講，一個清晰合理的調用是函數設計考量的重要一點，以前我要想到的是多閉包的狀況下最後一個標籤有可能被用戶調用時候省略，可是如今你說，不不，第一個纔會被強制省略？

蘋果怎麼辦呢？只好在 API 設計規範裏面說，你們如今開始要注意第一個尾閉包標籤會被省略，要給以後的尾閉包起個好的標籤名哦。

然而，這又解決了什麼問題呢？考慮到源代碼的兼容性，Swift 永遠不可能去掉第一種調用方法，用戶依舊可使用第一種寫法來使用多尾閉包的函數，因此上面所述的問題也會永遠存在。蘋果能夠作的不過是在從此新的多尾閉包寫法鋪開以後，悄咪咪地給第一種寫法加一些 warning 和自動轉換的功能吧。

引發那麼大爭論，我想蘋果如今很後悔爲何當初就不由止第一種寫法。若是當初禁止第一種寫法，如今的改動應該會是一片叫好吧。

那麼又是什麼緣由讓蘋果不惜背上被開發者噴的代價也要把這個特性加上呢？

哎，不是由於 SwiftUI 又是爲何呢？

蘋果鋪墊了那麼多，說是解決一個通用的多尾閉包的問題，最後才把真正的意圖亮出來，爲了 SwiftUI 的 API。

嚶嚶嚶，沒有多尾閉包，人家只能把 Section<Parent, Content, Footer> 設計成這個樣子啦！

init(header: Parent, footer: Footer, content: () -> Content)

// 調用
Section(
  header: ...,
  footer: ...
) {
  // content
}

複製代碼

這裏只有 content 才用上了 ViewBuilder 修飾的閉包 ViewBuilder 介紹，header 和 footer只能傳入實例，致使用戶必須寫一個新的類型才行。而理想狀況下，這三個參數都應該是 ViewBuilder 修飾的閉包：

init(content: () -> Content, header:() -> Parent, footer: () -> Footer)

// 調用
Section {
  // content
} header: {
  ...
} footer: {
  ...
}
複製代碼

而且 content 標籤是會被默認省略的，因此應當放到第一個。

咱們看一個新的 SwiftUI 的組件再來體會下：

struct Gauge<Label, CurrentValueLabel, BoundsLabel, MarkedValueLabels> where Label : View, CurrentValueLabel : View, BoundsLabel : View, MarkedValueLabels : View init<V>(value: V, in: ClosedRange<V>, label: () -> Label, currentValueLabel: () -> CurrentValueLabel, minimumValueLabel: () -> BoundsLabel, maximumValueLabel: () -> BoundsLabel) 複製代碼

終於能夠撒開了歡地用尾閉包了呢！

感謝wk_dev提醒，若是結合可空閉包默認值來看，問題還要複雜。下面這種之前想都不用想的函數調用，在你掌握了多尾閉包的知識後，你還知道test{}傳入的閉包是給header仍是footer嗎？

func test(header: (()->Void)? = nil, footer: (()->Void)? = nil) // 定義
test {} // 調用
複製代碼

按照單尾閉包來看，毫無疑問header爲nil，footer爲{}。

可是按照多尾閉包規則，我是否是能夠理解成header爲{}而footer由於默認值是nil被省略了呢？

事實上單尾閉包的規則起做用，因此爲了實現閉包可空，同時也是爲了解決語義不清晰的二義性問題，也只好用重載實現可空。

init<V>(value: V, in: ClosedRange<V>, label: () -> Label)
init<V>(value: V, in: ClosedRange<V>, label: () -> Label, currentValueLabel: () -> CurrentValueLabel)
init<V>(value: V, in: ClosedRange<V>, label: () -> Label, currentValueLabel: () -> CurrentValueLabel, markedValueLabels: () -> MarkedValueLabels)
init<V>(value: V, in: ClosedRange<V>, label: () -> Label, currentValueLabel: () -> CurrentValueLabel, minimumValueLabel: () -> BoundsLabel, maximumValueLabel: () -> BoundsLabel)
複製代碼

結語

一門開源語言的進化動力，不能僅僅來源於一個私有框架。在去年爲了 SwiftUI 引入大量新特性，而且最爲關鍵的 FunctionBuilder 至今沒有經過語言特性評審的狀況下，蘋果今年又獨斷獨行地引入多尾閉包這個爭議特性，可謂是走了一條與開源精神背道而馳的路。

Swift 今年號稱要推廣到更多的平臺，例如 Windows，這麼維護開發者關係的話，很難說到時候有多少人會站在你這一邊。