Expand usability of withMemoryRebound

withMemoryRebound の stride 制約を緩め、加えて生メモリ側にも同名 API を追加します。

許される T と Pointee の関係

rebind できる型の組み合わせを次のいずれかまで広げます。

• T と Pointee が layout equivalent である（同一型、typealias 関係、同じサイズ・アラインメントの trivial なスカラー型、クラスとそのスーパークラス、layout equivalent な要素からなる optional 参照やポインタ、1つの stored property だけを持つ struct とそのプロパティ型、など）
• T が Pointee の homogeneous aggregate である（例: Pointee が CGFloat で T が (CGFloat, CGFloat) や CGPoint）
• Pointee が T の homogeneous aggregate である（上の向きが逆のケース）

homogeneous aggregate とはタプル・配列ストレージ・frozen struct のように、同じ要素が連続して並んだ集合型を指し、要素数と各要素の layout が一致していれば互いに layout equivalent とみなされます。

この結果、従来の「stride が等しい」要件は「T の stride が Pointee の stride の整数倍、もしくはその整数分の 1 である」へと緩和されます。アラインメントが異なる場合は、ポインタ側が大きい方のアラインメントを満たしている必要があります。

また、この条件に当てはまらない rebind（まったく無関係な型への付け替え）をしたい場合は、一度生ポインタに変換してから後述の生メモリ版 withMemoryRebound を使うことになります。

これにより先ほどの Double → CGPoint の例はそのまま書けます。

var points = Array<CGPoint>(unsafeUninitializedCapacity: data.count/2) {
  buffer, initializedCount in
  pointer.withMemoryRebound(to: CGPoint.self, capacity: buffer.count) {
    buffer.baseAddress!.initialize(from: $0, count: buffer.count)
  }
  initializedCount = buffer.count
}

なお、capacity の意味は「rebind 後の T のインスタンス数」と明確化されます。stride が違ってもよくなった以上、Pointee の個数ではなく T の個数で数えるのが自然だからです。rebind 領域内の T は初期化済みでも未初期化でもかまいませんが、ある T に対応する Pointee の範囲は初期化状態が揃っている必要があります（混在は未定義動作）。

UnsafeBufferPointer / UnsafeMutableBufferPointer

typed buffer 側も同じ条件緩和を受けます。buffer 版はそもそも capacity 引数を取らず、T の要素数はもとの buffer のバイト数と T の stride からランタイムで自動計算されます。

extension UnsafeBufferPointer {
  public func withMemoryRebound<T, Result>(
    to type: T.Type,
    _ body: (_ buffer: UnsafeBufferPointer<T>) throws -> Result
  ) rethrows -> Result
}

UnsafeRawPointer / UnsafeMutableRawPointer への追加

生ポインタにも withMemoryRebound(to:capacity:_:) が生えます。生メモリを対象にするため、T には原則として型の制約が課されません（型安全性の担保は利用者の責任）。

ただし、その生ポインタが指すメモリがすでに何らかの型にバインドされている場合は、上で述べた UnsafePointer.withMemoryRebound のルールを満たす必要があります。つまり prebound な型と T が layout equivalent か、互いに homogeneous aggregate の関係にある、という条件です。一度もバインドされていない生メモリに対してはこの条件は適用されません。アラインメントについては、T のアラインメントに合っていることが常に必要です。

extension UnsafeRawPointer {
  public func withMemoryRebound<T, Result>(
    to type: T.Type,
    capacity count: Int,
    _ body: (_ pointer: UnsafePointer<T>) throws -> Result
  ) rethrows -> Result
}

extension UnsafeMutableRawPointer {
  public func withMemoryRebound<T, Result>(
    to type: T.Type,
    capacity count: Int,
    _ body: (_ pointer: UnsafeMutablePointer<T>) throws -> Result
  ) rethrows -> Result
}

UnsafeRawBufferPointer / UnsafeMutableRawBufferPointer への追加

生 buffer にも withMemoryRebound が追加されます。要素数は、もとの buffer のバイト数と T の stride から計算されます。もとのバイト数が T の stride の倍数でない場合、rebind 後の buffer はその分だけ短くなります。prebound な型がある場合の条件は生ポインタ版と同じです。

さらに「このメモリはすでに T にバインドされている」と分かっている場面向けに、assumingMemoryBound(to:) も追加されます。これは型付き buffer を返すだけの軽量な版で、count を自分で計算しなくて済みます。

extension UnsafeRawBufferPointer {
  public func withMemoryRebound<T, Result>(
    to type: T.Type,
    _ body: (_ buffer: UnsafeBufferPointer<T>) throws -> Result
  ) rethrows -> Result

  public func assumingMemoryBound<T>(to type: T.Type) -> UnsafeBufferPointer<T>
}

extension UnsafeMutableRawBufferPointer {
  public func withMemoryRebound<T, Result>(
    to type: T.Type,
    _ body: (_ buffer: UnsafeMutableBufferPointer<T>) throws -> Result
  ) rethrows -> Result

  public func assumingMemoryBound<T>(to type: T.Type) -> UnsafeMutableBufferPointer<T>
}

これらの追加のおかげで、Data 経由で受け取ったバイト列から CGPoint の配列を作る例も、load を回すコードではなく rebind 一回で書けるようになります。

var points = Array<CGPoint>(unsafeUninitializedCapacity: data.count/MemoryLayout<CGPoint>.stride) {
  buffer, initializedCount in
  data.withUnsafeBytes {
    $0.withMemoryRebound(to: CGPoint.self) {
      (_, initializedCount) = buffer.initialize(from: $0)
    }
  }
}

使う側への影響

既存の正しい利用コードはそのまま動きます。新しい緩和された意味論に依存するコードを古い標準ライブラリ上で動かすことはできませんが、更新後の実装は @_alwaysEmitIntoClient で提供されるため、古い OS にも back-deploy できます。