Offset-Based Access to Indices, Elements, and Slices

コレクションの「先頭からのオフセット」または「末尾からのオフセット」を表す OffsetBound という型を新しく導入し、それを使った添字や index(at:) を Collection / RangeReplaceableCollection に追加することで、先述の課題に応えます。

OffsetBound の使い方

OffsetBound は、コレクション自体を持たず「先頭から何番目」「末尾から何番目」という位置だけを表すバリューです。.first と .last がその起点で、+ / - でオフセット量を指定します。

let str = "abcdefghijklmnopqrstuvwxyz"
print(str[.first + 3 ..< .first + 6]) // "def"
print(str[.first + 3 ..< .last - 2])  // "defghijklmnopqrstuvw"
print(str[.last])                     // Optional("z")
print(str[.last - 1])                 // Optional("y")
print(str[.first + 26])               // nil（範囲外）
print(str[(.last - 3)...])            // "wxyz"

print(str.index(at: .last - 1))  // Optional(... "y" のインデックス)
print(str.index(at: .last - 25)) // Optional(... "a" のインデックス)
print(str.index(at: .last - 26)) // nil

位置が範囲外のときは nil、スライスは通常の部分範囲と同様にクランプされて空スライスが返る、という挙動です。低レベル API（index(_:offsetBy:) など）がトラップする場面でも、こちらはドメインエラーとして Optional で返します。

冒頭の parseRequirements は次のように書き直せます。

func parseRequirements(_ s: String) -> [(finish: Character, before: Character)] {
  s.split(separator: "\n").map { line in
    (line[.first + 5]!, line[.last - 11]!)
  }
}

Int インデックスのコレクションにまつわる誤解も、.first + n で「先頭から数えた位置」であることが明示的になるため回避しやすくなります。

print((3..<10)[(.first + 5)...]) // 8..<10

func fifth<C: Collection>(_ c: C) -> C.Element? { c[.first + 4] }

let array = [1,2,3,4,5,6,7,8,9]
print(fifth(array)!)       // 5
print(fifth(array[2...])!) // 7（従来は 5 が返って混乱のもとだった）

OffsetBound の比較

OffsetBound は Comparable に適合し、RangeExpression の Bound として使えるようになっています。.first からのオフセットと .last からのオフセットは、どれだけ大きな n, m を与えても前者が常に小さい、という順序が定義されます。

.first + n < .last - m   // どの n, m でも true
.first + n < .first + m  // n < m と同値
.last - n  < .last - m   // n > m と同値（.last に近いほど大きい）

実コレクションを伴わない純粋な位置の比較なので、必ずしも実際のコレクションが空でなかったときのインデックス順序と一致するわけではない点に注意は必要ですが、これにより範囲式を介した部分範囲（(.first + 3)... や ...(.last - 1) など）を素直にサポートできます。

Collection 側に追加される API

Collection に次の API が加わります。

extension Collection {
  func index(at position: OffsetBound) -> Index?
  subscript(position: OffsetBound) -> Element? { get }
  subscript<ORE: RangeExpression>(range: ORE) -> SubSequence
    where ORE.Bound == OffsetBound
}

計算量はコレクションの種類に応じて次のように保証されます。

• RandomAccessCollection なら O(1)
• BidirectionalCollection ならオフセット量に比例した O(k)
• .first + n や .last + 1 のような前方からの前進で済む形なら O(k)
• それ以外（末尾方向のオフセットで bidirectional でもない場合）は O(n)

この計算量保証のおかげで、双方向かどうかに関わらず動く汎用アルゴリズム（双方向なら速く、そうでなければ線形時間にフォールバックする、というもの）を自然に書けるようになります。

RangeReplaceableCollection 側に追加される API

変更も含めて OffsetBound で指せるよう、対応するメソッドと setter が追加されます。

extension RangeReplaceableCollection {
  mutating func replaceSubrange<C: Collection, R: RangeExpression>(
    _ subrange: R, with newElements: __owned C
  ) where C.Element == Element, R.Bound == OffsetBound

  mutating func insert(_ newElement: __owned Element, at position: OffsetBound)
  mutating func insert<S: Collection>(
    contentsOf newElements: __owned S, at position: OffsetBound
  ) where S.Element == Element

  mutating func remove(at position: OffsetBound) -> Element?
  mutating func removeSubrange<R: RangeExpression>(_ range: R)
    where R.Bound == OffsetBound

  subscript(position: OffsetBound) -> Element? { get set }
  subscript<ORE: RangeExpression>(range: ORE) -> SubSequence
    where ORE.Bound == OffsetBound { get set }
}

.last + 1 は「末尾の次の位置（＝endIndex）」を表し、そこへの insert は末尾追加に相当します。setter に nil を代入すると、その位置の要素を削除する挙動になります（要素アクセスの setter の場合）。

var abcs = "abcdefg"
abcs[.first + 2] = "C"
print(abcs) // "abCdefg"
abcs[.last - 1] = nil
print(abcs) // "abCdeg"

var rulers = "ルルル定規"
rulers.removeSubrange(.first + 1 ... .last - 1)
// 中央の文字を削除

内部カスタマイズポイントと suffix / dropLast の高速化

この提案では、_reverseOffsetIndex(_:by:) というアンダースコア付き（internal な位置づけ）のカスタマイズポイントが Collection に追加されます。既存の index(_:offsetBy:limitedBy:) は非双方向コレクションに負のオフセットを渡すとトラップしますが、こちらは双方向でないコレクションの場合に先頭から数え直すフォールバックを行い、呼び出し側からは常に「後方へのオフセット」として使えるようにするものです。BidirectionalCollection は効率的な実装で上書きします。

これに合わせて、Collection.suffix(_:) と Collection.dropLast(_:) の計算量保証も更新され、非双方向でも O(n) で完了することがドキュメント上も明記されます。結果として、BidirectionalCollection 側に重複して存在していた suffix / dropLast のオーバーロードは冗長になるため、新しいバージョンで obsolete 化されます。

設計上のトレードオフ

index(at:) や単一要素アクセスの添字が Optional を返すのは、これらが「要素の存在が呼び出し時点では保証されていない」高水準 API であるためです。低レベルな index(_:offsetBy:) や subscript(_:Index) は、前提条件違反を論理エラーとしてトラップする設計で、ループ内などの性能が重要な場面で使われます。一方、.first + n や .last - m は「範囲内かどうかわからない位置」を自然に扱う場面が多く、単純なドメインエラーとして nil で返すのが Swift の API 方針（Dictionary の subscript(_:Key) -> Value? や first/last、min() などと同じ方針）に沿うというのが Proposal の立場です。値が必ず存在するとわかっている箇所では、これまで通り末尾に ! を付けるのが自然な使い方です。