Swift 4.2 日本語化計画　: Swift 4.2

Swift 3 への移行

これは、Xcode 8 および Swift 2 から移行するための従来の文書です。

Xcode 8.0 には、プロジェクトを Swift 3 に移行するための Swift Migrator ツールが付属しています。また、Swift 2.3 で動作するように更新するツールと新しい SDK が付属します。

移行前の準備

最も効果的な移行を行うには、Xcode 7.3[.1] を使用する場合、移行しようとするプロジェクトが正常にビルドされ、すべてのテストに合格していることを確認してください。

また、プロジェクトがソース制御下で管理されていることを確認してください。これにより、移行アシスタントを介して適用された変更を簡単に確認したり破棄し、必要に応じて移行を再試行することができます。

異なる独立した製品 (または異なるプラットフォーム用の同じ製品) をビルドする複数のスキームがある場合は、プロジェクト内のすべてをビルドするスキームを一つ作成し、ユニットテストターゲットを含む必要なすべてのプラットフォーム用に作成することが重要です。移行アシスタントは、選択したスキームを使用して変更を収集するために、移行ツールを "ビルド" します。そして、処理されるターゲットは、スキームに含まれるものです。

スキームに含まれている内容を確認して変更するには、"スキームの編集..." シートを呼び出し、左側の列から "ビルド" タブを選択し、すべてのターゲットとユニットテストが含まれていることを確認します。

プロジェクトが Carthage または CocoaPods によって提供される他のオープンソースプロジェクトに依存する場合は、Carthage/CocoaPods プロジェクトの使用 のセクションを参照してください。

Swift 移行アシスタント

初めて Xcode 8.0 を使用してプロジェクトを開くと、移行アシスタントを経由して移行パスを実行するよう求められます。アシスタントはメニューから Edit -> Convert -> To Current Swift Syntax… で手動で呼び出すこともできます。

2 種類の移行から実行を選択できます。

• Swift 2.3 を使用する:プロジェクトを変更して Use Legacy Swift ビルド設定を有効にし、ソースの変更をして新しい SDK に対してビルドすることができます。
• Swift 3 を使用する:これをお勧めします。Swift 3 を使用してプロジェクトをビルドし、Xcode 8.0 のすべての新機能を利用できるように、ソースの変更が行われ、ビルドできます。

必要に応じて、今は Swift 2.3 に移動し、後で Swift 3 に更新するために、再度移行アシスタントを呼び出すことができます。

移行アシスタントを起動し、"Swift 2.3 の使用" または "Swift 3 の使用W" を選択すると、移行するターゲットのリストが表示されます。Swift コードを含まないターゲットは選択できません。

[次へ(Next)] をクリックすると、[プレビューを生成(Generate Preview)]シートが表示され、アシスタントはソースの変更を取得するために移行の 'ビルド' を開始します。これが完了して、[保存(Save)] をクリックすると適用されるすべての変更が表示されます。diff ビューでは、元のソース (変換前) が右側にあり、変更した物は左側にあることに注意してください。[保存(Save)] をクリックすると、ソースの変更が元のファイルに対して適用されます。Swift 2.3 への移行を選択した場合、ターゲットには "Use Legacy Swift" ビルド設定が適用されます。

ターゲットの処理に問題がある場合、移行プロセスに悪影響を及ぼします。[レポートナビゲータ(Report Navigator)] に切り替え、追加された[変換(Convert)] エントリを選択します。これは変換ビルドログです。ログに表示される可能性のあるエラーを確認して下さい。

ターゲットにコード署名できないというエラーが表示された場合は、ターゲットのビルド設定からコード署名を無効にしてみてください。

他のエラーが表示された場合は、バグレポートを https://bugreport.apple.com に提出し、詳細を記載してください。

回避策を適用する必要がある場合は、以前に移行アシスタントから受け入れた変更を破棄し、回避策を適用し、手動でアシスタントを呼び出して最初から変換を再試行して下さい。

Swift 3 移行変更の概要

Swift 3 には多くの重要な変更があり、移行ツールがそれであなたをお助けできます。Swift 3 の発展の提案の概要をここで見ることができます：https://github.com/apple/swift-evolution

よりインパクトのあるソース変更の概要を以下に示します。

API 設計ガイドライン

Objective-C API は、新しいSwift API 設計ガイドライン に従って Swift 3 にインポートされます。これは、SDK のインポート方法と Objective-C ユーザーフレームワークの両方に影響します。Swift 標準ライブラリには、ガイドラインを順守するための多くの変更点があります。詳細については、提案 SE-0005 - Objective-C API の Swift へのより良い翻訳 を参照してください。移行ツールは、新しいガイドラインに一致させるために、ユーザーが宣言した enum (列挙型) を小文字にしています。

SDK

CoreGraphics や Dispatch などの特定のフレームワークや Foundation からの他の型は、グローバル関数と変数のセットとしてではなく、それぞれの Swift 型のメンバー関数とプロパティとしてインポートされます。詳細については、SE-0044 - メンバーとしてのインポート と、SE-0088 - Swift 3 命名規則のための libdispatch の最新化 を参照してください。

Swift 3 では、基盤となる Foundation 型から "NS" 接頭辞が削除されつつあります。SE-0086 - Swift Foundation での NS 接頭辞の削除 を参照してください。

Swift 標準ライブラリ

コレクションのインデックス作成モデルは Swift 3 で劇的に変化しました。詳細は SE-0065 コレクションとインデックスの新しいモデル を参照してください。最も目に見える変化は、インデックスにはもはや successor()、predecessor()、advancedBy(_:)、advancedBy(_:limit:)、または distanceTo(_:) メソッドが存在しないことです。その代わりに、それらの操作はコレクションに移され、コレクションは現在インデックスの増分と減分を担当しています。

myIndex.successor()  =>  myCollection.index(after: myIndex)
myIndex.predecessor()  =>  myCollection.index(before: myIndex)
myIndex.advance(by: …) => myCollection.index(myIndex, offsetBy: …)

もし移行ツールがインデックスを担当するコレクションを知らない場合は、コレクションに記入する必要のあるエディタのプレースホルダを挿入します。

コレクションの変更をサポートするために、Range 型にもいくつかの変更が加えられました。以前は x..<y と x...y は同じ型の Range<T> を生成していました。今や、これらの式は、Range、CountableRange、ClosedRange、CountableClosedRange の 4 つの型のいずれか一つを生成できます。私たちは Range を Range と ClosedRange の型に分割して、型の最大値を含む閉じた範囲を作成します (たとえば、0...Int8.max が今は動作します)。単純な範囲型とそれらの ~Countable (カウント可能な) 相手は機能が異なります：

• Range<Bound> および ClosedRange<Bound> には、バインドにのみ Comparable が必要です。これにより、Range<String> を作成することができます。
• Range と ClosedRange は、Comparable だけの値を増分することができないため、繰り返し処理できません (これらはコレクションではありません)。
• CountableRange と CountableClosedRange は、それらのがバインドから Strideabe であることを必要とし、それらを反復処理できるように Collection に準拠している事を必要とします。

..< と ... 演算子は正しいことを行い、最も可能な範囲を返そうとします。つまり、for i in 1..<10 のようなコードは CountableRange を推測して動作し続けます。1 つの範囲型として型指定された変数があり、別の型を受け入れる API にそれを渡す必要がある場合は、変換する範囲型のイニシャライザを使用します。

var r = 0..<10 // CountableRange<Int>
Range(r) // converts to Range<Int>

言語

• 一貫した第一引数ラベル
  関数の最初の引数ラベルは API でデフォルトと見なされます。SE-0046 - 最初のラベルを含むすべてのパラメータにわたって一貫したラベル動作を確立する。 を参照の事。移行ツールは、アンダースコアラベルを追加して既存の API を保持します。



  func foo(bar: Int) => func foo(_ bar: Int)




• UnsafePointer<T>の処理に伴う変更
  Swift 3 では、UnsafePointer<Int>? のようなオプショナルを使用して、オブジェクトでないポインタ型のヌラブルが明示的に表されました。SE-0055 - オプショナルを使用して安全でないポインタのヌラブルを明示的にする を参照してください。これは、 UnsafePointer、UnsafeMutablePointer、 AutoreleasingUnsafeMutablePointer、OpaquePointer、Selector、および NSZone の型がヌラブルでないポインタ、つまり決して nil にならないポインタを表すようになったことを意味します。これらの型で動作するコードは、いくつかの変更を加える必要があります。


• ポインタを nil に設定するには、オプショナルでなければなりません。移行ツールはここで単純なケースを処理しますが、一般的にオブジェクト参照のようにポインタをオプショナルにする必要があるかどうかを判断しなければなりません。
• pointable プロパティ (以前の memory) または添え字要素にアクセスする前に、ヌラブルポインタを返す C 関数の結果を明示的に開封しなければなりません。オプショナルの連鎖構文はここでもうまくいきます。たとえば、result?pointee = sum。
• ポインタ型を受け取ったか返す呼び出し関数 (C 関数またはブロック) は、optional の使用または省略時の元の宣言と一致しなければなりません。
• コンパイラの制限により、C 変数 (NSLog など) を使用する関数にポインタを渡すことはできません。回避策として、代わりにポインタサイズの整数値として渡すために、以下の句を使用してください： Int(bitPattern:nullablePointer)。


• Objective-C の軽量汎用クラスは、汎用型としてインポートされました。
  SE-0057 - Objective-C の軽量汎用クラスのインポート
  Objective-C の汎用クラスは実行時に表現されないため、Swift で何ができるのかにはいくつかの制限があります。
• Objective-C 汎用クラスが as?、as!、または is キャストでチェックされて使用されている場合、汎用パラメータは実行時にチェックされません。パラメータに関係なく、オペランドが Objective-C クラスのインスタンスであれば、キャストは成功します。



let x = NSFoo<NSNumber>(value: NSNumber(integer: 0))
let y: AnyObject = x
let z = y as! NSFoo<NSString> // Succeeds




• Swift のサブクラスは、汎用パラメータが完全に指定されている場合にのみ、Objective-C 汎用クラスを継承できます。



// Error: Can't inherit Objective-C generic class with unbound parameter T
class SwiftFoo1<T>: NSFoo<T> { }
// OK: Can inherit Objective-C generic class with specific parameters
class SwiftFoo2<T>: NSFoo<NSString> { }




• Swift は Objective-C の汎用クラスを拡張できますが、拡張機能は制約することはできず、拡張機能内の定義はクラスの汎用パラメータにアクセスできません。



extension NSFoo {
  // Error: Can't access generic param T
  func foo() -> T {
    return T()
  }
}
    
// Error: extension can't be constrained
extension NSFoo where T: NSString {
}




• Foundation のコンテナクラス NS[Mutable]Array、NS[Mutable]Set、および NS[Mutable]Dictionary は、依然として非汎用クラスとして引き続きインポートされます。


• Objective-C id は Swift Any 型としてインポートされます。
  SE-0116 - Objective-C id を Swift Any 型としてインポートする
  id および型のないコレクションを使用する　Objective-C　インターフェイスは、AnyObject の代わりに Any　として Swift にインポートされます。


• ImplicitlyUnwrappedOptional の処理に伴う変更
  SE-0054 - ImplicitlyUnwrappedOptional 型を廃止
  以前に推論型 T! を右側に持っていた変数バインディングは、右辺のバインディングから、型 T? を持つようになりました。コンパイラは、これらのバインド変数がオプショナルでない型を要求するコンテキストで使用されているサイトでエラーを発生させ、その値を ！ 演算子で強制します。
  明示的に記述された、ネストされた IUO 型 ([Int!]など) は、コンテキストに適したものに応じて、対応するオプショナル型 ([Int?]) または非オプショナル型 ([Int]) を使用するように書き直さなければなりません。しかし、ネストされていない IUO 型の宣言の多くは、以前と同じように動作します。
  ImplicitlyUnwrappedOptional 型の unsugared の使用は、後置子の表記 ! で置き換えなければなりません。


• クロージャはデフォルトでエスケープされません
  SE-0103 - エスケープされないクロージャをデフォルトにする
  クロージャのデフォルトは切り替えられ、クロージャ引数が関数本体をエスケープできる場合は、 escaping 注釈が必要です。


• UnsafeRawPointer 型が導入され、安全でないポインタ変換に関して型の安全性が強化されました。
  SE-0107 - UnsafeRawPointer API
  Unsafe[Mutable]RawPointer 型が導入されました。Unsafe[Mutable]Pointer<Void> を置き換えます。 UnsafePointer<T> から UnsafePointer<U> への変換は許可されていません。Unsafe[Mutable]RawPointer は、型指定されていないメモリアクセス用の API と、メモリを型にバインドするための API を提供します。メモリをバインドすることで、ポインタ型間の変換を安全に行うことができます。
  コードを新しい API に移行する方法の詳細については、UnsafeRawPointer 移行ガイド を参照してください。

移行後

移行ツールは多くの機械的な変更を処理しますが、移行ツールの変更を適用した後にプロジェクトをビルドできるには、手動でさらに変更する必要があります。

関連する修正があるコンパイラエラーが表示されることがあります。移行ツールは Swift 3 コンパイラが提供する修正を組み込むように設計されていますが、これは 100％ 動作することが保証されていません (特にターゲット間に依存関係がある場合)。

それがうまくコンパイルされたとしても、移行ツールが提供するコードは '理想的' ではないかもしれません。たとえば、'NS' の接頭辞付きの型 (NSRL での url) へのキャストを見ることができ、代わりに新しい URL 値の型で関連した API を使用するようにコードを再構築した方が良いでしょう。移行ツールが追加した新しいコメント (/* Migrator FIXME：... */) が表示される場合もあります。このコメントには、コードの変換方法に関するヒントが表示されます。

プロジェクトの移行中に発生する可能性がある問題のリストについては、既知の移行の問題 セクションを参照してください。

Carthage/CocoaPods プロジェクトの使用

Xcode ワークスペースでプロジェクトと共にビルドされていない他のプロジェクトのバイナリの Swift モジュールを使用している場合は、以下のいずれかの移行方法から選択できます。

• Xcode ワークスペースにプロジェクトのソースコードを含める
  このアプローチでは、自分自信のプロジェクトと一緒にオープンソースプロジェクトをビルドし、移行します。Xcode 7.3[.1] を使用して、必要な変更を加え、プロジェクトがすべて正しくビルドされてリンクしていることを検証します。他の Xcode プロジェクトファイルをあなたのワークスペースに含め、あなたのプロジェクトが依存するターゲットをビルドするためのスキームを設定して下さい。Carthage のビルドフォルダ内でバイナリの Swift モジュールを検索するためのフレームワーク検索パスを設定している場合は、Xcode ワークスペースからビルドされた Swift モジュールのみを使用していることを確認するために、検索パスを削除するか、ビルドフォルダーをきれいにします。


• 上流のオープンソースプロジェクトが Swift 2.3 または Swift 3 に更新されるまで待ちます
  このワークフローに従ってプロジェクトを移行することができます。


• プロジェクトを Xcode 7.3 でビルドしている状態に保つ
• 移行アシスタントを起動し、自分自身のプロジェクトのみ (Swift 2.3 または Swift 3 の場合) に対して推奨されるソース変更を適用します。
• ビルドを試みる前に、Carthage/CocoaPods 依存ファイルを変更し、Swift 2.3 または Swift 3 に移行するプロジェクトの特定のタグ/分岐を指定してください。依存関係を更新し、更新された依存関係と、移行ツールから取得したソースの変更を使用してプロジェクトをビルドしてください。

既知の移行の問題

Swift 標準ライブラリ

• 移行ツールは、SetIndex および DictionaryIndex のインデックス作成メソッドの使用を移行できないことがあります。


• 回避策：インデックス作成メソッドをコレクションの対応するものに手動で移行します。
  概ね：
• index.successor() は Collection.index(after: index) に移行します。
• index.predecessor() は、 Collection.index(before: index) に移行します。
• index.advancedBy(delta) は、 Collection.index(index, offsetBy: delta) に移行します。
• index.advancedBy(delta, limit: otherIndex) は、 Collection.index(index, offsetBy: delta, limitedBy: otherIndex) に移行します。
• index.distanceTo(otherIndex) は、Collection.distance(from: index, to: otherIndex) に移行します。


• Swift 2.2 では、Unmanaged 型は、静的メソッド fromOpaque(_:) を持ち、インスタンスメソッド toOpaque() は、管理されない参照を COpaquePointer 型との間で変換しました。Swift 3 では、これらは、UnsafePointer<Void> からと UnsafeMutablePointer <Void> へと変換されるように変更され、C API の "コンテキストポインタ" として渡されることの一般的な使用に一致するように変更されました。ほとんどの場合、COpaquePointer (現在は OpaquePointer に名前が変更されています) の使用を単に削除することができます。
• ユーザー定義のコレクション型があれば、コンパイラー・エラー "'MyCollection'がプロトコル 'Collection' に適合しません。'" が表示されます。
• コレクションは今やインデックスの増分/減分を担当するようになりました。型を Collection に準拠させるには、メソッド func index(after:Index) -> Index を実装します。 BidirectionalCollection の場合は、func index(before:Index) -> Index も実装して下さい。
• RandomAccessCollection の場合は、func index(_:Index,offsetBy:Int) -> Index および func distance(from：Index,to:Index) -> IndexDistance も実装する必要があります。
• Sequence として使用されている半開放範囲演算子 (例えば 1 ..>2) から形成された Range 型の変数を持つ場合、for-in ループでは、エラーが発生して
  **“type ‘Range' does not conform to protocol 'Sequence'"** のようなメッセージが表示される可能性があります。
• 修正するには CountableRange に切り替えることです。
• ユーザーは、Collection.Index.Distance を Collection.IndexDistance (ドットなし) に手動で名前を変更する必要があります。
• Collection.enumerated() の結果にアクセスするときに、タプル要素 index の名前を offset に手動で変更する必要があるかもしれません。
• インデックスの範囲を移行した後に Range(Index) が Sequence のプロトコルに準拠していないというエラーが表示された場合は、コレクションの indices プロパティを使用て下さい。
• 例えば。for _ in str.startIndex..<someIndex {} –> for _ in str.indices[str.startIndex..>someIndex] {}
• イニシャライザ Zip2Sequence(_:_:) は削除されました。代わりに自由化関数 zip(_:_:) を使用してください。
• Collection への拡張機能の中で min / max を使用すると、Collection のネイティブメソッドとの衝突が発生する可能性があります。min / max の前にSwift を追加して問題を解決します。
• Selector() は nil に移行する必要があります。
• Range<>.reversed は削除されました。その機能をシミュレートするために、ユーザは <Collection>[<Range>].indices.reversed() を呼び出すことができます。
• 移行ツールは、Swift 3 に存在しない型の汎用制約を書き換えません。＆24868384
• 例えば、
  func foo<C: CollectionType where C.Index: BidirectionalIndexType>() {} は、func foo<C: BidirectionalCollection>() {} に移行すべきですが、その代わり func foo<C: Collection where C.Index: BidirectionalIndex>() {} に移行します。

SDK

• 一部のプロトコルは、新しい SDK リリースで新たに必要なメソッドを取得しました。移行ツールは現在、これらのメソッドの実装をあなたのコードに追加しません。
• 回避策：新しいプロトコル要件の実装を手動で追加します。
• Swift 3 では、Foundation の "文字列型 (stringly-typed)" API の多くが、新しい Notification.Name 型のような構造体の "wrapper types" を使うように変更されました。そのため、通知名やその他の文字列定数は、グローバルに宣言されたり、静的なメンバとして宣言されたりするのが一般的です。これらの新しい型を利用する最良の方法は、通常、宣言の時点でラッパー (wrapper) を構築することです。



static let MyGreatNotification = Notification.Name("MyGreatNotification")

// Use site (no change)
NotificationCenter.default().post(name: MyController.MyGreatNotification, object: self)'




• FileAttributeKey は、構造体の "ラッパー (wrapper) 型" を使用するように変更された "文字列型 (stringly-typed)" API の別のものです。このような型を辞書 (FileManager の attributesOfItem(atPath:) メソッドの結果など) で使用する場合、通常は文字列値を rawValue プロパティで抽出する必要があります。
• let mtime = try FileManager.default().attributesOfItem(atPath: "/")[FileAttributeKey.size.rawValue] as? NSNumber
• 移行ツールは、ほとんどの NSURL の使用を新しい値型の URL に変換します。しかし、Swift のエラー処理メカニズムを使用する代わりに out パラメータを通じてエラーを生成する checkResourceIsReachableAndReturnError のような NSURL の、いくつかのメソッドがあります。対応する URL のメソッドの checkResourceIsReachable は、エラー処理メカニズムを期待通り使用しています。＆26613405。
• Swift 3 の移行ツールは慎重で、NSURL メソッドを使用し続けます。URL 値型で新しい API を使用したい場合は、コードを手動で更新する必要があります。エラーを到達不能として扱う一般的なパターンについては、try ?　を使用することができます。let isReachable = (try? resourceURL.checkResourceIsReachable()) ?? false) (この特定の API では、あなたのためにキャストを処理する URL の resourceValues(forKeys:) に切り替えることをお勧めします)。
• NSURL の port プロパティはオプショナルの NSNumber を生成し、URL の対応するプロパティはオプショナルの Int です。Swift 3 の移行ツールは慎重で、NSURL プロパティを使用し続け、新しい API を使用したい場合は、コードを手動で更新する必要があります。
• 移行ツールは、NSData のほとんどの使用を新しい値型の Data に変換します。しかし、 UnsafeMutablePointer<Void> で動作する NSData の一部のメソッドはあり、Data の対応するメソッドは UnsafeMutablePointer <UInt8> を使用します。(例えば、NSData.getBytes(_:length:) は Data.copyBytes(_:length:) よりも受け入れられます。) 注意して下さい。Swift 型のメモリ内レイアウトは保証されません。
• 移行ツールは慎重であり、NSData メソッドを使用し続けます。新しい API を使用したい場合は、コードを手動で更新する必要があります。
• NSData(contentsOfMappedFile: x) は Data(contentsOf: x, options: .mappedAlways) に変更できます。
• NSData(data: x) は x に変更できます。
• 移行ツールは慎重ですが、Swift 3 ではより良い表現を持つ NSDate の用途がいくつかあります。
• (x as NSDate).earlierDate(y) は x < y ? x : y に変更できます。
• (x as NSDate).laterDate(y) は x < y ? y : x に変更できます。
• 移行ツールは、新しい SDK で case を獲得した文を切り替える case を追加しません。
• 回避策：switch 文に手動で case を追加し、適切な利用可能チェックを追加します。
• エラー：CALayer? から CALayer へのダウンキャストはオプショナルを開封するだけです。'!' を使うつもりでしたか？
• as! CALayer を削除して、! と置き換えて下さい。
• 移行ツールはグローバル定数を名前空間の列挙型 case に移行しますが、新しい列挙型の代わりに生の値を受け入れる関数に渡されたときに、適切な .rawValue 呼び出しを追加しない可能性があります。
• いくつかの型は現在汎用です (例えば、NSCache -> Cache<Key,Value>、NSMapTable -> MapTable<Key,Value> など)。Swift 3 に移行した後、それらに適切な汎用パラメータを追加する必要があります。
• オプショナルの Objective-C プロトコル要件を、準拠を宣言するクラスのサブクラスに実装すると、 "インスタンスメソッド '...' がプロトコル '...' のオプショナル要件 '...' とほぼ一致する という警告が表示されます。
• 回避策：元の Objective-C セレクタ内部にあるオプショナル要件の実装前に @objc(objectiveC:name:) 属性を追加します。
• リテラルをオプションとして使用すると、そのオプションの対応するコンストラクタを呼び出す必要があります。例えば、 NSWindowStyleMask(rawValue:8345)。
• 移行ツールは、値型に相当する (例えば、NSMutableData -> Data、NSMutableURLSession -> URLSession など) NSMutable* 型の使用を変更しませんが、ほとんどの SDK 関数では新しい値型が必要になります。


• 参照型から値の意味への変更を考慮して、慎重にこれらの型を同等の値型に変更します。すばやく回避するには、使用されている点(point) (例えば as Data) にキャストできますが、これにより追加コピーが作成される可能性があります。
• Swift 3 への移行後、"汎用 Objective-C クラスの拡張が実行時にクラスの汎用パラメータにアクセスできません" などのエラーが表示されることがあります。
• 拡張の内部から、署名に汎用パラメータを持つ汎用 Objective-C クラスからのメソッドを使用しようとするとき、これを避けるには、特定の型の self を消去する変数を使用して API を呼び出します。例えば： let typeErasedSelf = self as! MyObjCType<AnyObject>
• Pasteboard. readObjects(forClasses:options: ) のような関数を移行するとき、移行ツールは最初の引数の名前を積極的に変更することがあります。例えば、 NSURL.self は URL.self への移行、これはコンパイルエラーを引き起こします。この問題を解決するために、ユーザーは移行ツールの変更を破棄できます。
• NSData(bytes:length:deallocator:) の移行時に割り当て解除の型を移行ツールは変更しません。
• 回避策：型を (UnsafeMutablePointer<Void>, Int) -> Void から (UnsafeMutablePointer<Int8>, Int) -> Void へと変更します。
• ある特定のメソッドは、watchOS では使用できないとマークされていますが、iOS ではまだ必須です。これらの使用できないメソッドを上書きできないエラーが発生した場合は、＃if os(iOS) ブロックで囲んでください。
• ユーザーは String(contentsOfURL:usedEncoding:) への呼び出しを usedEncoding 引数の UnsafeMutablePointer の代わりに inout String.Encoding を受け入れる String(contentsOf:usedEncoding:) に手動で移行する必要があります。
• 移行ツールの自動変更後、一部の値型が NSURL から URL に変更され、使用できないメンバのコンパイラエラーが発生するかもしれません。この問題を解決するには、ユーザーは例えば x as NSURL のように、 URL でキャストを手動で追加する必要があります。
• ユーザーは、推論された型を使用してオプションセットを手動で簡素化したい場合があります。例えば DispatchQueue.global(attributes: DispatchQueue.GlobalAttributes.qosDefault) を DispatchQueue.global(attributes: .qosDefault) に変更します。
• ディスパッチ
• 自由化関数の dispatch_once は、Swift では使用できなくなりました。Swift では、遅延した、イニシャライズされたグローバルまたは静的プロパティを使用して、dispatch_once が提供するものと同じスレッドセーフと一度呼び出される保証を得ることができます。例えば：



  let myGlobal = { … global contains initialization in a call to a closure … }()
  _ = myGlobal  // using myGlobal will invoke the initialization code only the first time it is used.




• 現在、各 DispatchSource 型に固有のプロトコルがあります。dispatch_source_t は、 DispatchSourceTimer、DispatchSourceProcess など、これらの特定のプロトコルの 1 つに適宜変更する必要があります。
• Dispatch queue API は、今や DispatchAttributes OptionSet を使用するようになりました。以前に使用した
  dispatch_queue_attr_make_with_qos_class(DISPATCH_QUEUE_SERIAL, QOS_CLASS_DEFAULT, 0)) は、
  DispatchQueue(label: name, attributes: [.serial, .qosDefault]) で、オプションセットを使用して使用できます。
• dispatch_get_specific は今や UnsafeMutablePointer<Void> を取らなくなり、必要な引数ラベルを追加しません。
• 回避策：UnsafeMutablePointer<Void> キーを DispatchSpecificKey<T> に置き換え、なくなった key: ラベルを追加します。

Swift 3 言語

• 移行ツールは、ImplicitlyUnwrappedOptional (s) をとるクロージャを完全に移行することはできません。
• 回避策：通常のオプショナルを使用するように促します。
• 移行ツールが暗黙的に開封されたオプショナル型 ! を入れるべき所の値の後に誤って ? を挿入する可能性があります。これにより、確定的にトラッピングされる代わりに、nil 値を静かに伝播させることができます。
• 回避策：nil 値がトラップされる、このような場合には、? の代わりに ! を使用してください。
• if let 文がオプショナルを返さなくなった場合、移行ツールはその文を移行しません。
• 回避策：if let 文からその文を削除します。語彙のスコープを保持する必要がある場合は、バインディングを do 文の中に入れて下さい。
• 移行ツールは列挙型 case に先行ドットを追加しません。これは、移行ツールがそれらを小文字にするときに競合を引き起こす可能性があります。
• 回避策：まだ付いていない列挙型 case の先頭のドットを手動で追加します。
• NS の接頭辞を削除した後、名前が Foundation 型と競合するプロパティは、モジュールで修飾された型の名前になります。たとえば、var URL：NSURL がある場合、それは var URL: Foundation.URL として書き換えられます。
• 回避策：移行前にこれらのプロパティの名前を変更して、競合しないようにします。Swift の API ガイドラインでは、小文字にする必要があるとされています。
• String の生の値型を持つ Enum は、新しい Swift 命名ガイドラインに従うために手動で名前を変更する必要があります。
• 移行ツールは、SequenceType 準拠に不要な Swift モジュールの資格を追加する可能性があります。例えば、struct MySequence: SequenceType => struct MySequence: Swift.Sequence。
• 回避策：先頭の Swift. を削除します。

その他

• プロジェクト内に異なるターゲットをカバーする複数のスキームがある場合、そのうちの 1 つだけを移行する必要があるという通知が来ます。新しいスキームを手動で選択してから、Edit -> Convert -> To Current Swift Syntax を実行して、残りのスキームを移行する必要があります。または、プロジェクトからのすべてのターゲットを含むスキームを作成し、移行アシスタントを実行する前に選択しておくこともできます。