Unlock existentials for all protocols

「associated type 要件があるだけで、あるいは非共変な Self を持つ要件があるだけで、プロトコル全体を型として禁止する」という型レベルの制限を撤廃し、代わりに 個々のメンバーごと に existential からアクセス可能かどうかを判定するようにします。拡張メンバーに対して従来から行われていた扱いを、プロトコル要件にも揃える形です。

どのメンバーが existential から使えるか

プロトコル／プロトコル拡張のメンバー（メソッド・プロパティ・subscript・initializer。storage については各 accessor）は、そのメンバーの型（base 型を代入して見たもの）が、Self または Self をルートとする associated type を非共変位置に含まないかぎり existential 値から呼び出せます。

ここでの「共変位置」は次のように定義されます。

• 関数型の戻り値の位置
• タプル型の各要素の位置
• Swift.Optional の Wrapped の位置
• Swift.Array の Element の位置
• Swift.Dictionary の Value の位置

つまり、Self や associated type がこうした位置だけに現れるメンバーは existential から使える、ということです。

共変な Self と associated type の自動型消去

共変位置の Self はすでに「base となる existential 型そのもの」に自動で型消去されて呼び出せていました。

protocol Copyable {
  func copy() -> Self
}

func test(_ c: Copyable) {
  let x = c.copy() // OK, x の型は 'Copyable'
}

本提案では、これと同じ扱いを Self をルートとする associated type にも拡張します。共変位置に現れる associated type は、そのプロトコル上の制約から決まる上限型（class、プロトコル、プロトコル合成、あるいは Any）に型消去されます。

func test(_ collection: RandomAccessCollection) {
  // func dropLast(_ k: Int = 1) -> SubSequence
  let x = collection.dropLast() // OK, x の型は 'RandomAccessCollection'
}

associated type に「既知の実装」がある場合

associated type が same-type 制約などで具体型に固定されているとき、それは 既知の実装（known implementation） を持つとみなされ、Self をルートとする associated type 参照であってもメンバーアクセスを妨げません。

既知の実装は次のいずれかで与えられます。

• 明示的な same-type 制約（例: A == Int）
• superclass 制約など、他の経路から associated type に具体的な実装が見つかる場合

protocol IntCollection: RangeReplaceableCollection where Self.Element == Int {}
extension Array: IntCollection where Element == Int {}

var array: any IntCollection = [3, 1, 4, 1, 5]

array.append(9) // OK, 'Self.Element' は 'Int' と分かっている。

superclass 制約と組み合わせた例です。

class Class: P {
  typealias A = Int
}

protocol P {
  associatedtype A
}
protocol Q: P {
  func takesA(arg: A)
}

func testComposition(arg: Q & Class) {
  arg.takesA(arg: 0) // OK, 'A' は 'Int' と分かっている。
}

使えないメンバーの例

associated type やプロトコルを型として使えるようになっても、全ての要件が existential から呼べるわけではない 点には注意が必要です。たとえば Equatable の == は両辺の動的型が一致する保証がないため、existential 同士では呼び出せません。

let lhs: Equatable = "Paul"
let rhs: Equatable = "Alex"

lhs == rhs // error

if let ownerName = lhs as? String, let petName = rhs as? String {
  print(ownerName == petName) // OK, false
}

Sequence の enumerated() や RangeReplaceableCollection の append のように、Self や associated type を非共変位置に含むメンバーも existential 経由では呼べません。その場合は、ジェネリック制約に置き換えるとよい、というエラーが出ます。

func printEnumerated(s: Sequence) {
  // error: member 'enumerated' cannot be used on value of protocol type 'Sequence'
  // because it references 'Self' in invariant position; use a conformance constraint
  // instead. [fix-it: printEnumerated<S: Sequence>(s: S)]
  for (index, element) in s.enumerated() {
    print("\(index) : \(element)")
  }
}

let collection: RangeReplaceableCollection = [1, 2, 3]
// error: member 'append' cannot be used on value of protocol type
// 'RangeReplaceableCollection' because it references associated type 'Element'
// in contravariant position; use a conformance constraint instead.
collection.append(4)

関数・subscript のパラメータを起点にしたメンバーアクセスに対しては、コンパイラがそのパラメータをジェネリックパラメータに置き換える fix-it を提案します（ローカルコンテキストなどで generic function が書けない場合は fix-it は出ません）。

適合不能な existential

この変更に伴い、「その型自体に適合する型が原理的に存在しない」existential も書けるようになります。たとえば同じ associated type を別々の具体型に固定するプロトコルどうしを合成した P2 & Q2 のような型です。

protocol P1 { associatedtype A }
protocol P2: P1 where A == Int {}

protocol Q1 { associatedtype A }
protocol Q2: Q1 where A == Bool {}

func foo(_: P2 & Q2) {} // 適合可能な型は存在しない

こうした型を使うコード自体はデッドコードであり実行時に害はありません。ソース互換性のため、これらはエラーではなく、ジェネリックパラメータに対する同種の診断と同じく警告に留めます。

API 進化への効果

プロトコルに（デフォルト実装付きの）新しい要件を追加することが、常にソース互換かつバイナリ互換な変更になります。従来は「associated type 要件や非共変 Self を追加するとプロトコルを型として使っていたコードが壊れる」という落とし穴がありましたが、今後は個々のメンバー単位での判定になるため、既存の利用に影響しません。

Future Directions

本提案自体は generalized existentials に向けた足場づくりの位置付けで、以下のような発展が議論されています（いずれも将来の方向性であり、この提案で実現が約束されるものではありません）。

• AnyHashable や AnyCollection といった標準ライブラリの type-erasing wrapper の実装を、本提案の成果を使って簡素化する。
• existential 型を generic 引数に渡したときに自動で「開いて」扱えるようにする（self-conforming existentials）。
• AnyHashable に init(_ box: Hashable) を追加し、自動開放が入るまでのつなぎとする。
• some P と対をなす any P という明示的な existential 構文を導入する。
• any Collection<Self.Element == Int> のように existential に制約を付けて書けるようにする。