Identifiable Protocol

エンティティの同一性を値の等価性とは別に扱いたい場面は、多くのコードで発生します。たとえば連絡先を表す次のような型を考えます。

struct Contact {
    var id: Int
    var name: String
}

let john = Contact(id: 1000, name: "John Appleseed")
var johnny = john
johnny.name = "Johnny Appleseed"

ここで john と johnny は名前が異なるため値としては等しくありませんが、「同じ人物」を指しているという点では同一です。逆に、偶然別人と名前や他の属性が一致したとしても、それは「別人」です。このように、エンティティの状態（state）と同一性（identity）を区別して扱える仕組みが、ジェネリックなコードで広く必要とされます。

class の同一性では足りないケース

class のインスタンスであれば ObjectIdentifier や === で同一性を判定できます。しかし次のようなケースには対応できません。

• 値型（struct / enum）のスナップショット間で同一性を比較したい
• 永続化したデータや、プロセスをまたぐデータなど、インスタンスのメモリアドレスが共有できない状況で同一性を判定したい

また、値型に対して同一性を与えるためだけに class を導入するのは、割り当てコストの面でも不経済です。

ユーザーインターフェースにおける差分更新

代表的なユースケースのひとつがユーザーインターフェースの差分更新です。たとえば次のようなお気に入り連絡先リストを考えます。

struct FavoriteContactList: View {
    var favorites: [Contact]

    var body: some View {
        List(favorites) { contact in
            FavoriteCell(contact)
        }
    }
}

リストの中身が更新されたとき、良質な UX を提供するためには「エンティティの同一性」と「そのエンティティの状態の表現」を区別する必要があります。同一エンティティの state だけが変化した場合、古い要素を削除して新しい要素を挿入するのではなく、その場で更新するのが望ましい挙動です。さらに要素が移動しながら state も変わるようなケースも、差分アルゴリズムで正しく扱いたくなります。

こうした差分計算は UI 層だけでなくモデル層で行いたいこともあります。バックグラウンドで差分を計算してからメインスレッドで UI に反映したい、あるいは同じデータを複数のビューで表示しているため UI 層ごとに計算するのは無駄、といった状況です。モデル層のコードは UI フレームワークに依存したくないため、UI フレームワークが独自に定義した同一性プロトコルには頼れません。

各ライブラリが独自定義してしまう問題

標準ライブラリに同一性を表すプロトコルがないと、各ライブラリが似たようなプロトコルを独自に定義することになります。SwiftUI のように主要フレームワークが独自の Identifiable を持つと、他のライブラリは同じ概念なのに互いに互換性のない型を押し付けられることになり、結局どのライブラリもさらに自前の定義を用意せざるを得ません。共通概念として標準ライブラリに置くべき、というのがこの提案の動機です。