Swiftでのコピー不可な型の使用

Swiftでのコピー不可な型の使用

Swiftでコピー不可な型を使用する方法について説明します。Swiftでのコピーの意味、コピー不可な型を使用するケース、値の所有権によってデベロッパの意図を明確に示す方法を学びましょう。

関連する章
- 0:00 - Introduction
- 0:30 - Agenda
- 0:50 - Copying
- 7:05 - Noncopyable Types
- 11:50 - Generics
- 19:12 - Extensions
- 21:24 - Wrap up
リソース
関連ビデオ

WWDC19
- 最新のSwift APIのデザイン
ダウンロード

こんにちは SwiftチームのKavonです「Swiftでのコピー不可な型の使用」へようこそ私たちは一人ひとりが唯一の存在ですしかしSwiftの値はそうではありません値はコピーできるからです値が一意であると保証することはプログラミングにおいて強力な概念となります嬉しいことにこのたび Swiftにコピー不可な型を導入しました本日は多くのエキサイティングな内容をカバーしますまずコピーの仕組みについて復習します次に所有権とコピー不可な型についてお話しし最後にコピー不可な型のジェネリックな使用やこれらの型のExtensionの記述など高度なトピックについて説明しますそれでは始めましょう新しいゲームを開発しています絵文字をアイコンとして表す Player型を定義しました 2人のプレーヤーを作成しましょう現時点でこれらは同じです直感的に一方のアイコンを変えてももう一方のプレーヤーに影響しないことは分かりますその仕組みについて順を追って見ていきましょう最初の行でplayer1をカエルとして指定しますこの変数の内容は Playerを構成する実際のデータですこれが値型という構造体だからです player2に移ります player1と同じにしますどういう意味でしょうか player1のコピーを作成するという意味です変数をコピーするとその内容もコピーすることになります player2のアイコンを変更すると player1とは独立したPlayerを変更していることになります値のコピーや破棄について考える必要すらありませんでした Swiftが対応してくれるためです
では Playerが参照型であった場合はどうでしょうかそれは単に構造体からクラスに変更したということです先ほどと同じコードで何が起こるでしょうか最初のステートメントを分析してみましょう
PlayerClassを構築する際データを格納するためのオブジェクトが個別に割り当てられます
player1の内容はそのオブジェクトに対する自動管理参照となりますこれが参照型であることの意味です次のステートメントでは player2はplayer1と同じですつまり参照がコピーされるだけでオブジェクト自体がコピーされるわけではありませんこれはシャローコピーとも呼ばれる非常に高速なコピーです両方のプレーヤーが同じオブジェクトを参照するためアイコンを変更すると両方のアイコンが変わりますそのためこのアサーションは成り立ちませんどちらの場合もコピーの動作は同じでした唯一違う点は値をコピーするか参照をコピーするかという点ですイニシャライザを定義してディープコピーを行うことで参照型を値型のように動作させることができますこのイニシャライザは一例ですオブジェクトとそのオブジェクトが指すすべての要素を再帰的に再作成します
これを行うには Iconのイニシャライザを呼び出し別のPlayerのアイコンを使って再作成しますこれにより新しいプレーヤーは他のプレーヤーと参照を共有しません
先ほどのプログラムで player2をplayer1と同じにした状態に戻りディープコピーで動作がどのように変わるか確認しましょう
現時点では両方のプレーヤーが同じオブジェクトを参照しています
プレーヤーのフィールドに記述する前にそのイニシャライザを呼び出してディープコピーを作成します
これにより同一であるものの個別のオブジェクトが割り当てられ変更によって他の変数が影響を受けることがなくなります
これがコピーオンライト方式の本質です変更しても依存しないため値型と同じ動作が得られます
新しい型を設計する場合その値をディープコピーできるかどうかはすでに制御できていましたこれまで制御できなかったのは Swiftで自動的にコピーを作成できるかどうかです Copyableは型を自動コピーできるかどうかを記述する新しいプロトコルです Sendableと同様にメンバー要件はありません
デフォルトでは Swiftですべての要素が Copyableであると推論されますすべての要素ですすべての型が自動的に Copyableに適合しようとしますどのジェネリック型のパラメータでも入力する型は自動的に Copyableになりますすべてのプロトコルや関連する型も具象型が自動的に Copyableに適合し
すべてのボックス化されたプロトコル型も自動的にCopyableを含めて構成されます
先ほど紹介した通り Copyableと記述する必要はありません記述されていなくてもそのように設定されていますコピーの機能が必要であると Swiftで想定されている理由は Copyable型を扱う方がはるかに簡単であるためです
ただしコピーによってコードにエラーが発生しやすくなる状況もあります例えばバックエンドの銀行振替をモデル化するための型を記述するとします実際の振替は保留中キャンセル済み完了のいずれかです
この型には振替を完了する runメソッドを指定しますこれが振替のスケジュールを設定するための関数です誤って振替を2回行ったらユーザーの不満の原因になるためもう一度確認しましょう遅延が1秒未満であればすぐに実行しますしかし戻るのを忘れているため失敗して再度実行することになりますこのようなコストがかかる単純ミスにはどう対処すればよいでしょうかここで振替の状態を追跡する変数を追加してアサーションで再実行の試みが検出されるようにしますただしバグの検出テストを記述しない限りアサーションでバグは見つけられないためバックエンドサービスをダウンさせるようなバグが依然としてあります実はこのスケジュール関数にも別のバグがありますスリープ中のタスクがキャンセルされたらどうなるか考えてみましょうスローされたエラーを呼び出し元が慎重にチェックしないと振替をキャンセルし忘れることがあります
キャンセルを忘れず行うためのdeinitを BankTransferに追加する方法もありますしかしこれは実用的ではありません
startPayment関数を詳しく見てみましょう振替がスケジュールされたことの追跡用に振替のコピーを保持していますこれは問題ですすべてのコピーを破棄しないと振替のdeinitが実行されないためですこの問題の根本原因はプログラム内にあるこの振替のコピー数を制御できていない点です多くの場合値をコピーする機能は型のデフォルトとして適切ですが型をコピー不可にした方が適切な場合もあります BankTransferの問題は一旦置いておいてコピー不可な型について説明します
FloppyDiskをモデル化するとしますこのように記述するとデフォルトで Copyableに適合性がある型になりますただし適合性を宣言する部分で Copyableという単語の前にティルダを記述すると Copyableに対するデフォルトの適合性を抑止できますこれでFloppyDiskはCopyableにまったく適合しなくなりますティルダの付いたCopyableはその型のCopyableをなくすための宣言だと考えてみますそのフロッピーをコピーしようとするとどうなるでしょうかコピーはサポートされないため代わりにSwiftで使用されます
consumeと記述して明示的に指定できますが指定しなくてもそうなります
変数が使用されると値が取られその変数は初期化されないまま残ります
そのため使用する前にシステムディスクだけが初期化されます
使用することでシステムディスクのコンテンツがバックアップディスクに移動されます後でシステムディスクを読み込むと何も入っていないためエラーになります
次に新しいディスクを作成する関数について考えてみましょう formatを呼び出す場合変数resultはどうなるでしょうか関数のシグネチャにはディスクに渡す必要のある所有権が宣言されていないためどうなるかはわかりませんコピー可能なパラメータの場合この点を考慮する必要はありませんでした formatはディスクのコピーを事実上受け取ることになりますただしコピー不可なパラメータではコピーできないため関数が値に対して保持する所有権を宣言する必要があります
1つ目の種類の所有権は consumingと呼ばれるものです関数によって呼び出し元から引数が移動されることを意味します自分のものになるため変更することもできます
ただしここで引数を使用すると問題が発生します formatではディスクに何も返されないためですよく考えてみるとディスクをフォーマットする場合一時的にアクセスするだけで済みます
一時的にアクセスする場合それを借りることになります borrowingでは letバインディングのように引数への読み取りアクセスが付与されます
内部ではほぼすべてのパラメータやメソッドが Copyable型に対してこのように機能します
違いは明示的に借りた引数は使用または変更できないという点ですコピーしかできませんこのformat関数では最終的にディスクに変更を加える必要があるため borrowingも使えません
最後の種類の所有権は皆さんもご存知のinoutですこれはメソッドにおける mutatingの記述と同じものです
Inoutでは呼び出し元にある変数への一時的な書き込みアクセスを許可します書き込み権限があるためパラメータを使用できますただし関数が終了する前の　ある時点で inoutパラメータの再初期化が必要です呼び出し元は復帰時に値があることを想定しているためですでは BankTransferの例に戻りましょう使用可能なリソースとしてモデル化できるようになったためですまず BankTransferをコピー不可な構造体として指定し runメソッドをconsumingとマークしましたこれにより selfの値が呼び出し元から移動されますこの2つの変更だけでアサーションも不要になりました Swiftで同じ振替に対してrunメソッドを 2回呼び出すことができなくなりました所有権は正確に追跡されるためこの構造体にdeinitを追加すれば破棄された場合に runではなくアクションがトリガされます runメソッドが終了すると自動的にselfが破棄されるため discard selfと記述しますこれでdeinitを呼び出すことなく selfが破棄されます schedule関数のバグがどうなるか見てみましょうまず transferパラメータに所有権を追加する必要があります scheduleは最後の使用を意図しているため consumingが理にかなっていますコンパイルしようとすると Swiftでバグが検出されています ifステートメントがフォールスルーするため transferが2回使用される可能性がありますそれを防ぐためreturnを追加しますではもう一つのバグはどうでしょうかこれも定義済みです scheduleがtransferの最後の所有者であるため sleepが投げられるとdeinitが実行され振替がキャンセルされます
コピー不可な型はプログラムの正確性を高める上で優れたツールになりますジェネリックコードを含めあらゆる場所で使いたいと思うでしょう Swift 6ではコピー不可なジェネリクスを使うことができますこれは新しいジェネリクスシステムということではなく Swiftの既存のジェネリクスモデルをベースとしていますここでジェネリクスについて再確認しましょう
まず Swiftにある型の世界について考えてみましょうすべての型がうまく共存しています Stringも Commandと呼ばれる独自の型もあります
プロトコルRunnableはこの世界の部分空間を定義し適合する型が含まれています現時点では適合するものがないため空になっていますもしRunnableに適合するように Commandを拡張するとこの点はRunnable空間に移動しますジェネリクスの核となる考え方は適合制約がジェネリック型を記述するということです executeと呼ばれるジェネリック関数で考えてみましょう山括弧の中に入っているTはこの世界に存在する型を表す新しいジェネリック型パラメータを宣言していますがどの型かはわかりません Copyableはあらゆる場所に適用されていると説明しましたがこのTにはデフォルトで制約があります入力型がCopyableに適合している必要があるのです
Commandはデフォルトで Copyableに適合しており RunnableもCopyableを継承しています最近まで明示されてはいないものの Swiftにあるすべての型がCopyableでした
つまりこの空間に含まれるすべての型を execute関数に渡すことができます唯一の制約はTが Copyableに適合することだからです
CommandはRunnableにも適合していますがより広範なCopyableの空間にも依然として存在しており特定の型がRunnableである場合もそうでない場合もありますこのジェネリックパラメータTでは追加の適合性を持つ型は除外していません前述の通り execute関数では Copyable以外の適合性は必要ありません
ただし execute関数を実装するために TをRunnableにして runメソッドを呼び出す必要がありますそこで where句を使って TにRunnable制約を追加します
これにより Tに許容される型の空間にさらに制約を設けたことになります RunnableとCopyableの組み合わせで空間が絞り込まれています Commandは含まれていますが Stringは除外されました StringにはRunnableに対する適合性がないためです
Swift 5.9以来この世界は拡大し続けています Copyableに適合しない型も存在するためです例えば新しく登場した BankTransfer型は適合しないため点は外側にあります Copyableの適合性を抑止するにはティルダ付きのCopyableを記述するしかなくこれをより広範な空間と呼んでいます
なじみのあるSwiftの型のほとんどが Copyableに適合していますではそれらはティルダ付きのCopyable内にどのように含まれているのでしょうか
先ほどと同様より広範なこの空間では Copyableに適合する特定の型を想定することはできません Copyableである場合もそうでない場合も考えられるとしてティルダ付きのCopyableを理解する必要があります
Any型はどうでしょうかこれは常にCopyableでありそうあるべきですほぼすべてのプログラミング言語ではどの型もCopyableです
これでコピー不可なジェネリクスについて説明できます先ほどのRunnableプロトコルから見ていきましょう
型の世界は現在このようになっています Runnableの値はすべてCopyableです
BankTransferはCopyableではないため Runnableにも含まれませんただし BankTransferも適合させたいためジェネリクスとして使用します Runnable型をコピーする機能はプロトコルにとって不可欠ではないためティルダ付きのCopyableを追加して RunnableからCopyable制約を削除します
階層が変わり Copyable空間がRunnableを含むのではなく重なるだけになります CommandはRunnableかつCopyableとなり重なり合う部分に収まります次に Runnableの適合性で BankTransferを拡張するとこの点はCopyableとは重なり合わない Runnableの部分に移動します
ジェネリック関数executeに話を戻しましょう
ジェネリックパラメータTにはまだデフォルトの制約があるため RunnableかつCopyableである Commandのような型だけが executeで許可されています
ティルダ付きのCopyableを使って TからCopyable制約を削除します
制約を取り除くことで許可される型は Runnableであるすべての型に広がります execute関数でTはCopyableでない可能性があることを示唆していますこれが重要なポイントです通常の制約は許可される型を絞り込んで具体的に指定しますがティルダ制約は具体的な指定を緩和させることで幅を広げますではこれらの理論を実践してみましょう Runnable型を Jobという新しい構造体に含めたいと思いますジェネリックパラメータActionを Jobに定義しています ActionはRunnableですが Copyableでない可能性がありますこのままの記述ではエラーが発生してしまいます Job構造体はデフォルトで Copyableに適合しているため Copyableのデータのみを含められますコピー不可な値を別の値に格納する方法は2通りありますクラスをコピーしても参照だけがコピーされるようクラス内に格納する方法と格納されている型自体のCopyableを抑止する方法ですここでは2つ目の方法を使い Jobをコピー不可にします
この場合も依然としてActionに Command型を指定できます ActionはCopyable型が表示されるのを阻止しないためです JobではActionをコピーする必要がないためコピー不可な型も機能しますただし Actionに指定した型が Copyableである場合はどうなるでしょうか Jobはアクションを入れるだけの入れ物なのでコピーできます
Jobを条件付きでCopyableと宣言することで API作成者としてコピーを許可できます Extensionでは ActionがCopyableの場合に JobもCopyableになると宣言されています
型の世界でどう見えるかと言うと
Actionの具体的な型に指定するまで JobがCopyableかどうかわかりませんでは Commandを使いましょう
CommandはCopyableであるため JobのCommandもCopyableです
ActionをBankTransferに変えると適合性条件が満たされないため JobのBankTransferは Copyableになりません
コピー不可なジェネリクスの全体的な考え方としてはデフォルトのCopyable制約を除去するということですコピー不可なジェネリックパラメータで型を定義する方法を説明しましたこの型のExtensionについて詳しく見ていきましょう Actionのgetterメソッドを定義するとします
Jobの通常のExtensionを使って追加します
呼び出すのは問題ありませんがこれはActionのコピーでしょうかそうですアクションを返す際にコピーされますこれはExtensionのエラーではありません
このプレーンなExtensionはデフォルトでJobに制約されておりそのActionはCopyableであるためです
つまりこのgetterは正常です BankTransferジョブの場合は呼び出し可能でないためです Extensionの仕組みとしては Extension型の範囲内にあるジェネリックパラメータはCopyableに制約されプロトコルのSelfも該当します
このようにExtensionを動作させるのは優れたメリットがあります Jobが自分で記述していない JobKitモジュールの一部であるとします Cancellable型を記述するプロトコルがここにありますコピー不可な型が何かわからないもののとにかくJobを適合させたいとしますこのExtensionを記述すれば機能するため問題ありません
適合性には Actionが Copyableであるという条件がデフォルトで付いているためです一般にActionはCopyableでないため ActionがCopyableとなる場合 Jobも CopyableとなりCancellableに適合します
このJob型を公開することで Copyable型だけを扱うプログラマがこれを使うことができますでは Copyableを問わずこのExtensionをすべてのジョブに適用したい場合はどうすればよいでしょうか
このExtensionのActionから Copyable制約を取り除くだけで ActionがCopyableかどうかを想定せずに JobがCancellableに適合されます
本日は Swiftにおけるコピーの仕組みとコピーで生まれる課題について見てきました所有権について考える必要はありますがコピー不可な型はプログラムの正確性を高める上で有用なツールとなります紹介したステップによって Optional UnsafePointer Resultを使いコピー不可なジェネリクスを標準ライブラリに追加できるようになります詳しくはSwift Evolutionの提案事項をお読みくださいコピー不可なジェネリクスや borrowingとconsumingのパターンマッチングコピー不可な標準ライブラリのプリミティブについて確認できます「Swift Programming Language」ブックでも詳しく学ぶことができますもっと全般的にコピーオンライト方式やジェネリック型を設計する際のベストプラクティスについて学びたい方は WWDC 2019の「Modern Swift API Design」をご覧くださいご視聴ありがとうございました WWDCをお楽しみください

struct Player {
  var icon: String
}

func test() {
  let player1 = Player(icon: "🐸")
  var player2 = player1
  player2.icon = "🚚"
  assert(player1.icon == "🐸")
}

1:55 - Player as a class

class PlayerClass {
  var icon: String
  init(_ icon: String) { self.icon = icon }
}

func test() {
  let player1 = PlayerClass("🐸")
  let player2 = player1
  player2.icon = "🚚"
  assert(player1.icon == "🐸")
}

3:00 - Deeply copying a PlayerClass

class PlayerClass {
  var data: Icon
  init(_ icon: String) { self.data = Icon(icon) }

  init(from other: PlayerClass) {
    self.data = Icon(from: other.data)
  } 
}

func test() {
  let player1 = PlayerClass("🐸")
  var player2 = player1
  player2 = PlayerClass(from: player2)
  player2.data.icon = "🚚"
  assert(player1.data.icon == "🐸")
}

struct Icon {
  var icon: String
  init(_ icon: String) { self.icon = icon }
  init(from other: Icon) { self.icon = other.icon }
}

5:10 - Copyable BankTransfer

class BankTransfer {
  var complete = false

  func run() {
    assert(!complete)
    // .. do it ..
    complete = true
  }

  deinit {
    if !complete { cancel() }
  }

  func cancel() { /* ... */ }
}

func schedule(_ transfer: BankTransfer,
              _ delay: Duration) async throws {

  if delay < .seconds(1) {
    transfer.run()
  }

  try await Task.sleep(for: delay)
  transfer.run()
}

func startPayment() async {
  let payment = BankTransfer()
  log.append(payment)
  try? await schedule(payment, .seconds(3))
}

let log = Log()

final class Log: Sendable {
  func append(_ transfer: BankTransfer) { /* ... */ }
}

7:46 - Copying FloppyDisk

struct FloppyDisk: ~Copyable {}

func copyFloppy() {
  let system = FloppyDisk()
  let backup = consume system
  load(system)
  // ...
}

func load(_ disk: borrowing FloppyDisk) {}

8:18 - Missing ownership for FloppyDisk

struct FloppyDisk: ~Copyable { }

func newDisk() -> FloppyDisk {
  let result = FloppyDisk()
  format(result)
  return result
}

func format(_ disk: FloppyDisk) {
  // ...
}

9:00 - Consuming ownership

struct FloppyDisk: ~Copyable { }

func newDisk() -> FloppyDisk {
  let result = FloppyDisk()
  format(result)
  return result
}

func format(_ disk: consuming FloppyDisk) {
  // ...
}

9:26 - Borrowing ownership

struct FloppyDisk: ~Copyable { }

func newDisk() -> FloppyDisk {
  let result = FloppyDisk()
  format(result)
  return result
}

func format(_ disk: borrowing FloppyDisk) {
  var tempDisk = disk
  // ...
}

9:55 - Inout ownership

struct FloppyDisk: ~Copyable { }

func newDisk() -> FloppyDisk {
  var result = FloppyDisk()
  format(&result)
  return result
}

func format(_ disk: inout FloppyDisk) {
  var tempDisk = disk
  // ...
  disk = tempDisk
}

10:28 - Noncopyable BankTransfer

struct BankTransfer: ~Copyable {
  consuming func run() {
    // .. do it ..
    discard self
  }

  deinit {
    cancel()
  }

  consuming func cancel() {
    // .. do the cancellation ..
    discard self
  }
}

11:10 - Schedule function for noncopyable BankTransfer

func schedule(_ transfer: consuming BankTransfer,
              _ delay: Duration) async throws {

  if delay < .seconds(1) {
    transfer.run()
    return
  }

  try await Task.sleep(for: delay)
  transfer.run()
}

12:12 - Overview of conformance constraints

struct Command { }

protocol Runnable {
  consuming func run()
}

extension Command: Runnable {
  func run() { /* ... */ }
}

func execute1<T>(_ t: T) {}

func execute2<T>(_ t: T) 
  where T: Runnable {
  t.run()
}

func test(_ cmd: Command, _ str: String) {
  execute1(cmd)
  execute1(str)

  execute2(cmd)
  execute2(str) // expected error: 'execute2' requires that 'String' conform to 'Runnable'
}

15:50 - Noncopyable generics: 'execute' function

protocol Runnable: ~Copyable {
  consuming func run()
}

struct Command: Runnable {
  func run() { /* ... */ }
}

struct BankTransfer: ~Copyable, Runnable {
  consuming func run() { /* ... */ }
}

func execute2<T>(_ t: T)
  where T: Runnable {
  t.run()
}

func execute3<T>(_ t: consuming T)
  where T: Runnable,
        T: ~Copyable {
  t.run()
}

func test() {
  execute2(Command())
  execute2(BankTransfer()) // expected error: 'execute2' requires that 'BankTransfer' conform to 'Copyable'

  execute3(Command())
  execute3(BankTransfer())
}

18:05 - Conditionally Copyable

struct Job<Action: Runnable & ~Copyable>: ~Copyable {
  var action: Action?
}

func runEndlessly(_ job: consuming Job<Command>) {
  while true {
    let current = copy job
    current.action?.run()
  }
}

extension Job: Copyable where Action: Copyable {}

protocol Runnable: ~Copyable {
  consuming func run()
}

struct Command: Runnable {
  func run() { /* ... */ }
}

19:27 - Extensions of types with noncopyable generic parameters

extension Job {
  func getAction() -> Action? {
    return action
  }
}

func inspectCmd(_ cmdJob: Job<Command>) {
  let _ = cmdJob.getAction()
  let _ = cmdJob.getAction()
}

func inspectXfer(_ transferJob: borrowing Job<BankTransfer>) {
  let _ = transferJob.getAction() // expected error: method 'getAction' requires that 'BankTransfer' conform to 'Copyable'
}


struct Job<Action: Runnable & ~Copyable>: ~Copyable {
  var action: Action?
}

extension Job: Copyable where Action: Copyable {}

protocol Runnable: ~Copyable {
  consuming func run()
}

struct Command: Runnable {
  func run() { /* ... */ }
}

struct BankTransfer: ~Copyable, Runnable {
  consuming func run() { /* ... */ }
}

20:14 - Cancellable for Jobs with Copyable actions

protocol Cancellable {
  mutating func cancel()
}

extension Job: Cancellable {
  mutating func cancel() {
    action = nil
  }
}

21:00 - Cancellable for all Jobs

protocol Cancellable: ~Copyable {
  mutating func cancel()
}

extension Job: Cancellable where Action: ~Copyable {
  mutating func cancel() {
    action = nil
  }
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

関連する章

リソース

関連ビデオ

WWDC19