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

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

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

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

這是因?yàn)镃urrentValueSubject是一個(gè)泛型類型，實(shí)例化時(shí)不僅需要Output類型，還需要Failure類型——這是該主體能夠拋出的錯誤類型。

因?yàn)槲覀儾幌Ｍ覀兊闹黧w在這種情況下拋出任何錯誤，所以我們會給它一個(gè)Failure類型的值Never(這是在 Swift 中使用 Combine 的一個(gè)常見慣例)。但為了做到這一點(diǎn)，在 Swift 5.6 之前，我們需要明確地指定我們的Int輸出類型——像這樣：

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

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

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

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

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

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

上面的函數(shù)使用了一個(gè)相當(dāng)復(fù)雜的泛型作為它的返回類型，這可能是因?yàn)槲覀冃枰诙鄠€(gè)地方中重復(fù)使用我們的Resource類型，也因?yàn)槲覀冞x擇了使用*幻象類型*來指定我們當(dāng)前處理的是哪種PDF。

現(xiàn)在讓我們看看，如果我們在創(chuàng)建主體時(shí)調(diào)用上述函數(shù)，而不是僅僅使用一個(gè)簡單的整數(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)
)

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

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

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

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

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

但這并不意味著類型別名在通常情況下都比類型占位符好，因?yàn)槿绻覀円獮槊糠N特定情況定義新的類型別名，那么這也會使我們的代碼庫變得更加復(fù)雜。有時(shí)，在內(nèi)聯(lián)中指定所有的東西(比如使用類型占位符時(shí))絕對是個(gè)好辦法，因?yàn)檫@可以讓我們定義完全獨(dú)立的表達(dá)式。

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

enum UserRole {
    case local
    case remote
}
let latestMessages: [UserRole: _] = [
    .local: "",
    .remote: ""
]

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