Swift 4のロードマップ

2017年後半にリリース予定のSwift 4は，ソースコードとABIレベルの両面で言語の安定化を目標としている。新たな機能としてはジェネリクスの改善と，Rust/Cycloneにヒントを得たメモリ所有権モデルがある。

Swift 4の開発は２つのステージに分割されている。最初のステージにはSwift ABIの安定化に必要なすべての機能が含まれると同時に，Swift 3とのソース互換性も確保される。第２のステージにはまだ未定義な部分もあるが，大小さまざまな言語の新機能が含まれる予定だ。これらについては，既存の言語機能のABIを変更しないことと，あるいは標準ライブラリの互換性を損なわないことが保証される。

ソース互換性

ソースの互換性に対するニーズは基本的なものであるが，言語を安定化することは，その言語の進化する能力を損なう可能性もある。互換性を保ちながら言語を急速に発展させるため，Swiftチームは既存の@available属性を拡張し，特定のプラットフォームやOSに対してのみではなく，Swfit言語の過去バージョンとの相関関係も示すようにした。

例えば次のように，Swift 3.1で廃止されたAPIを宣言することができる。

@available(swift, obsoleted: 3.1)
class Foo {
  //...
}

ABIの安定性

SwiftのABIを安定させる上でまず必要なのは，新機能を追加するための基盤をレイアウトすることだ。これはレジリエンシ(resiliency)と呼ばれる機能で，ABIの安定性の保証と公開APIの発展との両立を可能にする。これは例えば，ABIを棄損せずに変更できるAPIの部分を明示化することで実現可能になる。こうすることで，オブジェクト指向言語の一部で発生する，ベースクラスの脆弱性に関する問題を解消できる。

一方でABIの安定化には，その言語に関する既存の不備な部分を解決して，それが恒久的なものにならないようにする必要もある。具体的な改善点のいくつかは，すでに特定されている。例えば，

• 条件付き適合(conditional conformances) あるジェネリック型について，その引数の型が一定の要件を満たす場合にのみ特定のプロトコルに適合する，という概念を表現する。要素がEquatableな場合にのみEquatableプロトコルを実装可能なArrayコレクションなどがその例だ。

  extension Array: Equatable where Element: Equatable {
    static func ==(lhs: Array<Element>, rhs: Array<Element>) -> Bool { ... }
  }
  

• 再帰的プロトコル要件 関連する型を外部のプロトコルに適応させることができる。例えばSubsequenceはそれ自体がSequenceなので，Swift 4では，従来ならば不適合だった次のような定義が可能になる。

  protocol Sequence {
    associatedtype Iterator : IteratorProtocol
    ...
    associatedtype SubSequence : Sequence   // currently ill-formed, but should be possible
  }
  

• 関連する型に対するwhere句 ジェネリック型ではすでに利用可能なwhere句に，関連する型に対する新たな表現力をもたらす。例えば,

  protocol Sequence {
    associatedtype Iterator : IteratorProtocol
    associatedtype SubSequence : Sequence where SubSequence.Iterator.Element == Iterator.Element
    ...
  }
  

最後に紹介する大きな成果は，CycloneやRustの機能からインスパイアされたメモリ所有件モデルだ。これはシステムプログラマや，決定論的なパフォーマンスが強く求められるすべてのケースにおいて，非常に有益なものになる。メモリ所有権モデルを加えたことによってSwiftは，ABIの変更方法を理解するための統合的デザインを確立するという，そのステージ１の限界を超えて拡張されることになる。