標準のSwift値型は、暗黙のコピーとARCによってヒープに割り当てられたリソースを管理し、値を関数の境界を越えて自由に複製できるようにします。それに対して、~Copyableとして宣言された構造体（非コピー可能）は、暗黙のコピーを完全に禁止し、一意の所有権を強制します。そのような構造体が関数に渡されると、Swiftは明示的な所有権注釈を要求します：consumingは所有権を呼び出し側に永久に転送し、borrowingは移動やコピーせずに一時的な読み取り専用アクセスを付与し、inoutは一時的な排他的可変アクセスを提供します。このモデルは、移動のみのリソースに対するARCのオーバーヘッドを排除し、移動後の使用や二重コピーエラーに対するコンパイル時の安全性を保証します。
私たちは、高頻度取引アプリケーションを構築しており、2MBの市場データパケットがカーネル空間のDMAバッファを表現しており、一貫性とパフォーマンスのためにユニークである必要がありました。
問題： このバッファを処理段階間で渡す（ネットワーク取り込み、検証、戦略エンジン）際に、基盤となるメモリを複製したり、ホットパスで参照カウントをトリガーしないこと。 標準のクラスは許容できないARCレイテンシを引き起こしましたが、手動のunsafeポインタはメモリリークやダングリング参照のリスクを伴いました。
解決策1：参照カウントクラス。 バッファをdeinitハンドラを持つクラスにラップすることを検討しました。利点には、馴染みのあるメモリ管理や簡単な共有が含まれました。しかし、欠点は深刻でした：コンポーネント間を渡るたびに、キャッシュの局所性を破壊し、100マイクロ秒のレイテンシ要件に違反する原子保持/解放操作が発生しました。
解決策2：Unsafe生ポインタ。 UnsafeMutablePointer<UInt8>を手動割り当てで使用することで、ARCを完全に回避しました。利点はオーバーヘッドがゼロで完全な制御が可能でした。欠点は、コンパイル時の安全性保証が欠如していたこと—開発者は簡単にバッファを二重解放したり、解放されたメモリにアクセスしたりすることができ、生産環境でクラッシュを引き起こす可能性がありました。
解決策3：所有権修飾子を持つ非コピー可能な構造体。 我々はポインタを含むstruct MarketDataBuffer: ~Copyableを定義しました。バッファを受け取る関数は、所有権を取得するためにconsumingを使用しました（例：func process(_ buffer: consuming MarketDataBuffer)）、一方、検査関数はborrowingを使用しました（例：func validate(_ buffer: borrowing MarketDataBuffer)）。これにより、一意の所有権をコンパイル時に強制し、ランタイムオーバーヘッドをゼロにしました。
選択した解決策と結果： 解決策3を選択しました。その結果、コンパイラが偶発的なコピーや移動後の使用エラーを防ぎ、決定論的なデータパイプラインが実現しました。システムはパケットをゼロのARCトラフィックで処理し、DMAバッファは常にひとつの論理的所有者を持つことが保証され、レイテンシの一貫性が大幅に向上しました。
関数パラメータをconsumingとしてマークすると、関数が返った後に呼び出し側が非コピー可能な値を使用できなくなるのはなぜですか？
パラメータがconsumingとしてマークされると、関数はエントリ時に値の所有権を取得します。~Copyable型の場合、これはコピーではなく破壊的移動を構成します。呼び出し側は値を放棄し、関数呼び出しが完了した後、元の変数は初期化されなくなり、アクセスできなくなります。アクセスしようとすると、コンパイル時エラーが発生します。これにより、線形所有権が強制され、値はその寿命の間に正確に1つの所有者を持つことが保証されます。コピー可能な型に対しては、consumingが要件を満たすために暗黙のコピーをトリガーしますが、非コピー可能な型に対しては複製は発生しません。
なぜ非コピー可能な型はSwiftバージョン6.0以前の標準的なジェネリックコレクション（例えばArray）に格納できないのですか？
Swift 6.0以前は、標準ライブラリのジェネリック型は、その型パラメータがCopyableに準拠していることを暗黙的に要求していました。非コピー可能な型は~Copyable制約を使用して明示的にCopyableから外れるため、この暗黙的な要件に違反し、ArrayやOptionalに格納できませんでした。Swift 6.0は非コピー可能なジェネリックを導入し、コンテナが~Copyable制約を伝播させることによって非コピー可能な要素を条件付きでサポートできるようにしました。ただし、appendなどの操作はconsumingセマンティクスを使用する必要があり、コレクション自体は非コピー可能な要素を含む場合、非コピー可能になります。そのため、API境界での所有権の取り扱いに注意が必要です。
非コピー可能な型に対してborrowingパラメータ修飾子と従来のinout修飾子を適用した場合の違いは何ですか？
borrowing修飾子は、所有権を移転せずに値への一時的で不変のアクセスを付与します。呼び出し側は値を保持し、関数が返った後も引き続き使用できます（関数内で消費されていない場合）。対照的に、inoutは可変借用を表します：所有権を一時的に移動させ、関数の呼び出しの間に値を関数内に移動させて変更を許可し、その後元に戻します。非コピー可能な型に対しては、borrowingが所有権を放棄せずに読み取り専用の検査を行うために重要であり、inoutは変更のために必要です。重要なのは、borrowingは関数が値を消費または移動するのを防ぎますが、inoutは値が呼び出し側に有効な、潜在的に変更された状態で戻ることを保証する点です。