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

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

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

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

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

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

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

不過(guò)從 Swift 5.6 開(kāi)始，這種情況就不存在了——因?yàn)槲覀儸F(xiàn)在可以使用一個(gè)類型占位符來(lái)表示我們主體的Output類型，這讓我們?cè)俅卫镁幾g器為我們自動(dòng)推斷出該類型，就像在聲明一個(gè)普通的Int值一樣：

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

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

**但現(xiàn)在讓我們看看這個(gè)功能如何擴(kuò)展到更復(fù)雜的類型，這是它真正開(kāi)始發(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擇了使用*幻象類型*來(lái)指定我們當(dāng)前處理的是哪種PDF。

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

// 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)在完全來(lái)自 loadAnnotatedPDF 函數(shù)，這可能會(huì)使該函數(shù)（及其相關(guān)代碼）的迭代更加容易——因?yàn)槿绻覀兏淖冊(cè)摵瘮?shù)的返回類型，需要更新的手動(dòng)類型注釋將減少。

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

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

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

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

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

在我們總結(jié)之前，讓我們也來(lái)看看類型占位符是如何與集合字面量(literals)一起使用的——例如在創(chuàng)建一個(gè)字典時(shí)。在這里，我們選擇手動(dòng)指定我們的字典的 Key 類型（為了能夠使用點(diǎn)語(yǔ)法來(lái)指代枚舉的各種情況），同時(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í)使用。

總結(jié)

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

最新評(píng)論