Eliminate IndexDistance from Collection

Collection プロトコルには、2つのインデックス間の距離を表す関連型として IndexDistance がありました。IndexDistance は SignedInteger に適合する任意の整数型にできる設計で、標準ライブラリでも多くのAPIで使われていました。

protocol Collection {
    associatedtype IndexDistance: SignedInteger
    var count: IndexDistance { get }
    func index(_ i: Index, offsetBy n: IndexDistance) -> Index
    func distance(from start: Index, to end: Index) -> IndexDistance
    // ...
}

ジェネリックなコレクション処理を書く上での大きな障害になっていた

実際の利用現場では、インデックス間の距離はほぼ常に Int です。それでも関連型として抽象化されているために、Collection を使ったジェネリックなアルゴリズムを書こうとすると、次のような手間が必要になっていました。

• リテラルに明示的な型注釈が要る。たとえば let i = 0 ではなく let i: IndexDistance = 0 と書かないと型が決まらない
• 距離型の違うコレクション同士をまたぐと numericCast での変換が必要になる
• その numericCast が正しい向きの変換になっているか（大きな型から小さな型への変換で溢れないか）を人間が判断しなければならない

結果として、コレクションに対するジェネリックな処理を書くという問題が、同時に数値型の変換問題にもなってしまっていました。Swift 4.0 で関連型への where 制約（SE-0142）が入り、再帰的なプロトコル制約（SE-0157）の対応も進んで、中級者でもジェネリックなアルゴリズムを書けるようになりつつあったなかで、IndexDistance はその最後の、そして最大の障害として残っていました。

実質的に Int を前提にしたコードが溢れていた

こうした事情から、標準ライブラリの外でも「どうせ Int だろう」として where IndexDistance == Int を付けてジェネリック性を諦めるコードが多く、さらには Index == Int まで固めてしまうコードも珍しくありませんでした。標準ライブラリ内部のジェネリックコードも、Int.max を超えるサイズのコレクションを渡されれば実際にはトラップする作りになっているものが多く、「Int 以外の距離型を本気で想定したコード」はほとんど存在しないのが実情でした。

また、IndexDistance がジェネリックに残っていることはコンパイラの最適化（特殊化）にも不利で、コンパイル時間を押し上げる要因にもなっていました。

Swift 公式のガイダンス自体、特別な理由がない限り整数型には Int を使うよう勧めています。IndexDistance の存在はこの指針とも噛み合っておらず、数十億要素を超える巨大コレクションや、Int より小さい距離型で省メモリ化したい極端に小さなコレクションといったニッチなユースケースのためだけに、すべてのジェネリックコードに恒常的なコストを課している状態でした。