Swift 的類型推斷能力從一開始就是語言的核心部分，它極大地減少了我們在聲明有默認(rèn)值的變量和屬性時手動指定類型的工作。例如，表達(dá)式var number = 7不需要包含任何類型注釋，因為編譯器能夠推斷出值7是一個Int，我們的number變量應(yīng)該被相應(yīng)的類型化。

作為 Xcode 13.3 的一部分而一起發(fā)布的 Swift 5.6，通過引入 "類型占位符（type placeholders） "的概念，繼續(xù)擴(kuò)展這些類型推理能力，這在處理集合和其他通用類型時非常有用。

例如，假設(shè)我們想創(chuàng)建一個Combine里面具有默認(rèn)整數(shù)值的 CurrentValueSubject的實例。關(guān)于如何做到這一點的初步想法可能是簡單地將我們的默認(rèn)值傳遞給該主體的初始化器，然后將結(jié)果存儲在本地的一個let聲明的屬性中（就像創(chuàng)建一個普通的Int值時一樣）。然而，這樣做會給我們帶來以下編譯器錯誤：

// Error: "Generic parameter 'Failure' could not be inferred"
// Error: “無法被推斷出泛型的`Failure`參數(shù) ”
let counterSubject = CurrentValueSubject(0)

這是因為CurrentValueSubject是一個泛型類型，實例化時不僅需要Output類型，還需要Failure類型——這是該主體能夠拋出的錯誤類型。

因為我們不希望我們的主體在這種情況下拋出任何錯誤，所以我們會給它一個Failure類型的值Never（這是在 Swift 中使用 Combine 的一個常見慣例）。但為了做到這一點，在 Swift 5.6 之前，我們需要明確地指定我們的Int輸出類型——像這樣：

let counterSubject = CurrentValueSubject<Int, Never>(0)

不過從 Swift 5.6 開始，這種情況就不存在了——因為我們現(xiàn)在可以使用一個類型占位符來表示我們主體的Output類型，這讓我們再次利用編譯器為我們自動推斷出該類型，就像在聲明一個普通的Int值一樣：

let counterSubject = CurrentValueSubject<_, Never>(0)

這很好，但可以說這并不是 swift 里面很大的改進(jìn)。畢竟，我們用_代替Int只是節(jié)省了兩個字符，而且手動指定像Int這樣的簡單類型也不是一開始就有問題的。

**但現(xiàn)在讓我們看看這個功能如何擴(kuò)展到更復(fù)雜的類型，這是它真正開始發(fā)光的地方。**例如，假設(shè)我們的項目包含以下函數(shù)，讓我們加載一個用戶注解的PDF文件:

func loadAnnotatedPDF(named: String) -> Resource<PDF<UserAnnotations>> {
    ...
}

上面的函數(shù)使用了一個相當(dāng)復(fù)雜的泛型作為它的返回類型，這可能是因為我們需要在多個地方中重復(fù)使用我們的Resource類型，也因為我們選擇了使用*幻象類型*來指定我們當(dāng)前處理的是哪種PDF。

現(xiàn)在讓我們看看，如果我們在創(chuàng)建主體時調(diào)用上述函數(shù)，而不是僅僅使用一個簡單的整數(shù)，那么我們之前基于CurrentValueSubject的代碼會是什么樣子:

// Before Swift 5.6:
let pdfSubject = CurrentValueSubject<Resource<PDF<UserAnnotations>>, Never>(
    loadAnnotatedPDF(named: name)
)

// Swift 5.6:
let pdfSubject = CurrentValueSubject<_, Never>(
    loadAnnotatedPDF(named: name)
)

這是一個相當(dāng)大的改進(jìn)啊 基于 Swift 5.6 的版本不僅為我們節(jié)省了一些輸入，而且由于 pdfSubject 的類型現(xiàn)在完全來自 loadAnnotatedPDF 函數(shù)，這可能會使該函數(shù)（及其相關(guān)代碼）的迭代更加容易——因為如果我們改變該函數(shù)的返回類型，需要更新的手動類型注釋將減少。

不過，值得指出的是，在上述情況下，還有另一種方法可以利用Swift的類型推理能力——那就是使用類型別名，而不是類型占位符。例如，我們可以在這里定義一個UnfailingValueSubject類型別名，我們可以用它來輕松地創(chuàng)建不會產(chǎn)生任何錯誤的主體：

typealias UnfailingValueSubject<T> = CurrentValueSubject<T, Never>

有了上述內(nèi)容，我們現(xiàn)在就可以在沒有任何泛型注解的情況下創(chuàng)建我們的pdfSubject了——因為編譯器能夠推斷出T指的是什么類型，而且失敗類型Never已經(jīng)被硬編碼到我們的新類型別名中:

let pdfSubject = UnfailingValueSubject(loadAnnotatedPDF(named: name))

但這并不意味著類型別名在通常情況下都比類型占位符好，因為如果我們要為每種特定情況定義新的類型別名，那么這也會使我們的代碼庫變得更加復(fù)雜。有時，在內(nèi)聯(lián)中指定所有的東西（比如使用類型占位符時）絕對是個好辦法，因為這可以讓我們定義完全獨立的表達(dá)式。

在我們總結(jié)之前，讓我們也來看看類型占位符是如何與集合字面量(literals)一起使用的——例如在創(chuàng)建一個字典時。在這里，我們選擇手動指定我們的字典的 Key 類型（為了能夠使用點語法來指代枚舉的各種情況），同時為該字典的值使用一個類型占位符：

enum UserRole {
    case local
    case remote
}

let latestMessages: [UserRole: _] = [
    .local: "",
    .remote: ""
]

這就是類型占位符——Swift 5.6 中引入的一個新功能，在處理稍微復(fù)雜的通用類型時，它可能真的很有用。但值得指出的是，這些占位符只能在調(diào)用站點使用，而不是在指定函數(shù)或計算屬性的返回類型時使用。

總結(jié)

到此這篇關(guān)于Swift類型占位符的文章就介紹到這了,更多相關(guān)Swift類型占位符內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論