Sendable? 和 @Sendable 是 Swift 5.5 中的并發修改的一部分，解決了結構化的并發結構體和執行者消息之間傳遞的類型檢查的挑戰性問題。

應該在什么時候使用 Sendable？

Sendable協議和閉包表明那些傳遞的值的公共API是否線程安全的向編譯器傳遞了值。當沒有公共修改器、有內部鎖定系統或修改器實現了與值類型一樣的復制寫入時，公共API可以安全地跨并發域使用。

標準庫中的許多類型已經支持了Sendable協議，消除了對許多類型添加一致性的要求。由于標準庫的支持，編譯器可以為你的自定義類型創建隱式一致性。

例如，整型支持該協議：

extension Int: Sendable {}

一旦我們創建了一個具有 Int 類型的單一屬性的值類型結構體，我們就隱式地得到了對 Sendable 協議的支持。

struct Article {
    var views: Int
}

與此同時，同樣的 Article 內容的類，將不會有隱式遵守該協議：

class Article {
    var views: Int
}

類不符合要求，因為它是一個引用類型，因此可以從其他并發域變異。換句話說，該類文章(Article)的傳遞不是線程安全的，所以編譯器不能隱式地將其標記為遵守Sendable協議。

使用泛型和枚舉時的隱式一致性

很好理解的是，如果泛型不符合Sendable協議，編譯器就不會為泛型添加隱式的一致性。

struct Container<Value> {
    var child: Value
}

然而，如果我們將協議要求添加到我們的泛型中，我們將得到隱式支持：

struct Container<Value: Sendable> {
    var child: Value
}

對于有關聯值的枚舉也是如此：

如果枚舉值們不符合 Sendable 協議，隱式的Sendable協議一致性就不會起作用。

你可以看到，我們自動從編譯器中得到一個錯誤：

Associated value ‘loggedIn(name:)’ of ‘Sendable’-conforming enum ‘State’ has non-sendable type ‘(name: NSAttributedString)’。

我們可以通過使用一個值類型String來解決這個錯誤，因為它已經符合Sendable。

enum State: Sendable {
    case loggedOut
    case loggedIn(name: String)
}

從線程安全的實例中拋出錯誤

同樣的規則適用于想要符合Sendable的錯誤類型。

struct ArticleSavingError: Error {
    var author: NonFinalAuthor
}

extension ArticleSavingError: Sendable { }

由于作者不是不變的（non-final），而且不是線程安全的（后面會詳細介紹），我們會遇到以下錯誤：

Stored property ‘author’ of ‘Sendable’-conforming struct ‘ArticleSavingError’ has non-sendable type ‘NonFinalAuthor’。

你可以通過確保ArticleSavingError?的所有成員都符合Sendable協議來解決這個錯誤。

隱式一致性消除了很多我們需要自己為Sendable協議添加一致性的情況。然而，在有些情況下，我們知道我們的類型是線程安全的，但是編譯器并沒有為我們添加隱式一致性。

常見的例子是被標記為不可變和內部具有鎖定機制的類：

final class User: Sendable {
    let name: String

    init(name: String) { self.name = name }
}

你需要用@unchecked屬性來標記可變類，以表明我們的類由于內部鎖定機制所以是線程安全的：

extension DispatchQueue {
    static let userMutatingLock = DispatchQueue(label: "person.lock.queue")
}

final class MutableUser: @unchecked Sendable {
    private var name: String = ""

    func updateName(_ name: String) {
        DispatchQueue.userMutatingLock.sync {
            self.name = name
        }
    }
}

Sendable協議的一致性必須發生在同一個源文件中，以確保編譯器檢查所有可見成員的線程安全。

例如，你可以在例如 Swift package這樣的模塊中定義以下類型：

public struct Article {
    internal var title: String
}

Article 是公開的，而標題title是內部的，在模塊外不可見。因此，編譯器不能在源文件之外應用Sendable一致性，因為它對標題屬性不可見，即使標題使用的是遵守Sendable協議的String類型。

同樣的問題發生在我們想要使一個可變的非最終類遵守Sendable協議時：

可變的非最終類無法遵守 Sendable 協議。

由于該類是非最終的，我們無法符合Sendable?協議的要求，因為我們不確定其他類是否會繼承User?的非Sendable成員。因此，我們會遇到以下錯誤：

Non-final class ‘User’ cannot conform to ?Sendable?; use ?@unchecked Sendable?。

正如你所看到的，編譯器建議使用@unchecked Sendable?。我們可以把這個屬性添加到我們的User類中，并擺脫這個錯誤：

class User: @unchecked Sendable {
    let name: String

    init(name: String) { self.name = name }
}

然而，這確實要求我們無論何時從User繼承，都要確保它是線程安全的。由于我們給自己和同事增加了額外的責任，我不鼓勵使用這個屬性，建議使用組合、最終類或值類型來實現我們的目的。

函數可以跨并發域傳遞，因此也需要可發送的一致性。然而，函數不能符合協議，所以Swift引入了@Sendable屬性。你可以傳遞的函數的例子是全局函數聲明、閉包和訪問器，如getters和setters。

SE-302的部分動機是執行盡可能少的同步。

我們希望這樣一個系統中的絕大多數代碼都是無同步的。

使用@Sendable屬性，我們將告訴編譯器，他不需要額外的同步，因為閉包中所有捕獲的值都是線程安全的。一個典型的例子是在Actor isolation中使用閉包。

actor ArticlesList {
    func filteredArticles(_ isIncluded: @Sendable (Article) -> Bool) async -> [Article] {
        
    }
}

如果你用非 Sendabel 類型的閉包，我們會遇到一個錯誤：

let listOfArticles = ArticlesList()
var searchKeyword: NSAttributedString? = NSAttributedString(string: "keyword")
let filteredArticles = await listOfArticles.filteredArticles { article in    
    guard let searchKeyword = searchKeyword else { return false }
    return article.title == searchKeyword.string
}

當然，我們可以通過使用一個普通的String來快速解決這種情況，但它展示了編譯器如何幫助我們執行線程安全。

Xcode 14 允許您通過 SWIFT_STRICT_CONCURRENCY 構建設置啟用嚴格的并發性檢查。

啟用嚴格的并發性檢查，以修復 Sendable 的符合性。

這個構建設置控制編譯器對Sendable和actor-isolation檢查的執行水平：

• Minimal : 編譯器將只診斷明確標有Sendable一致性的實例，并等同于Swift 5.5和5.6的行為。不會有任何警告或錯誤。
• Targeted:  強制執行Sendable約束，并對你所有采用async/await等并發的代碼進行actor-isolation檢查。編譯器還將檢查明確采用Sendable的實例。這種模式試圖在與現有代碼的兼容性和捕捉潛在的數據競賽之間取得平衡。
• Complete:  匹配預期的 Swift 6語義，以檢查和消除數據競賽。這種模式檢查其他兩種模式所做的一切，并對你項目中的所有代碼進行這些檢查。

嚴格的并發檢查構建設置有助于 Swift 向數據競賽安全邁進。與此構建設置相關的每一個觸發的警告都可能表明你的代碼中存在潛在的數據競賽。因此，必須考慮啟用嚴格并發檢查來驗證你的代碼。

Enabling strict concurrency in Xcode 14

你會得到的警告數量取決于你在項目中使用并發的頻率。對于Stock Analyzer，我有大約17個警告需要解決：

并發相關的警告，表明潛在的數據競賽。

這些警告可能讓人望而生畏，但利用本文的知識，你應該能夠擺脫大部分警告，防止數據競賽的發生。然而，有些警告是你無法控制的，因為是外部模塊觸發了它們。在我的例子中，我有一個與SWHighlight有關的警告，它不符合Sendable，而蘋果在他們的SharedWithYou框架中定義了它。

在上述SharedWithYou框架的例子中，最好是等待庫的所有者添加Sendable支持。在這種情況下，這就意味著要等待蘋果公司為SWHighlight實例指明Sendable的一致性。對于這些庫，你可以通過使用@preconcurrency屬性來暫時禁用Sendable警告：?

@preconcurrency import SharedWithYou

重要的是要明白，我們并沒有解決這些警告，而只是禁用了它們。來自這些庫的代碼仍然有可能發生數據競賽。如果你正在使用這些框架的實例，你需要考慮實例是否真的是線程安全的。一旦你使用的框架被更新為Sendable的一致性，你可以刪除@preconcurrency屬性，并修復可能觸發的警告。