質問への回答

Swift 5.1はSE-0258を通じてプロパティラッパーを導入し、反復的なアクセサーボイラープレートを排除しました。 projectedValue要件は、ラップされた値自体を超えた二次APIサーフェス（例：SwiftUIのBindingや検証状態）を公開するために設計されました。この機能により、開発者は$プレフィックス構文を使ってメタデータや投影にアクセスできます。

問題は、Swiftが宣言的構文を有効なSIL（Swift Intermediate Language）に変換する必要があることであり、名前の衝突を引き起こさず、アクセス制御を破らないようにする必要があります。コンパイラは、ラップされたプロパティの値セマンティクスを維持しながら、投影を通じて参照セマンティクスを公開するストレージを合成しなければなりません。また、$プレフィックスの識別子がユーザー定義のメンバーと衝突しないようにする必要があります。

解決策は、ソースからソースへのデシュガリングを含みます。 @Wrapper var property: Tとして宣言されたプロパティの場合、コンパイラは3つの異なるメンバーを生成します。まず、型Wrapper<T>のプライベートストレージ変数_property。次に、_property.wrappedValueにget/set操作を転送する計算プロパティproperty。最後に、_property.projectedValueを返す計算プロパティ$property。$プレフィックスのプロパティは、元の宣言のアクセス制御を引き継ぎ、コンパイラは$構文が利用されるときにprojectedValueが存在することを強制します。

@propertyWrapper
struct Validating<T> {
    var wrappedValue: T
    var projectedValue: ValidationState<T>
    
    init(wrappedValue: T) {
        self.wrappedValue = wrappedValue
        self.projectedValue = ValidationState(value: wrappedValue)
    }
}

// デシュガリング後のコード:
struct Form {
    private var _username: Validating<String>
    
    var username: String {
        get { _username.wrappedValue }
        set { _username.wrappedValue = newValue }
    }
    
    var $username: ValidationState<String> {
        get { _username.projectedValue }
    }
}

生活からの状況

私たちは、各フィールドがその現在の値と、以前のエラーや修正タイムスタンプを含む複雑な検証履歴を追跡する必要がある医療データ入力アプリケーションを設計していました。この課題は、UIテキストフィールドの生の文字列とアナリティクスおよびエラー表示のための検証履歴の2つの異なるデータパスを単一のプロパティ抽象から公開することを要求しました。

最初に考慮されたアプローチは、プロパティ名をValidationHistoryオブジェクトにマッピングする並行辞書を維持することでした。これによりストレージの柔軟性が得られましたが、リファクタリング中に壊れるストリング型APIが導入され、辞書と実際のプロパティ値との手動同期が必要になりました。医療データに対して、古いエラー表示につながる非同期化のリスクは許容できませんでした。

2番目のアプローチは、値と履歴の両方を含むラッパー構造体を作成し、その複合型をプロパティ型として使用することでした。型安全ではありましたが、ドメインモデルに検証の懸念を持ち込むことになり、すべてのアクセスサイトがアンラッピングを扱う必要があり、UIとビジネスロジックの間のクリーンアーキテクチャの分離の目的を無効にしました。

3番目のアプローチは、projectedValueがValidationHistory参照型を返すカスタム@Validatedプロパティラッパーを利用しました。これにより、内部での同期がカプセル化されながら、履歴アクセスのために$fieldNameを公開しました。このアプローチは、ラップされた文字列値のCoW（Copy-on-Write）セマンティクスを維持し、検証履歴の安定した参照アイデンティティを提供し、UIコンポーネントが変更を観察できるようにし、コピーオーバーヘッドを回避しました。

その結果、全く新しいクラスの同期バグが排除され、検証関連のコードベースが35％削減されました。$構文は、ジュニア開発者に直感的な発見性を提供し、コンパイル時の強制がモジュール境界を越えた実装詳細の偶発的な公開を防ぎました。

候補者がしばしば見逃すこと

なぜ値型のprojectedValueへの変異はドル記号プレフィックス経由でアクセスされると持続しないのか？

プロパティラッパーが構造体である場合、projectedValueのゲッターは値のコピーを返します。projectedValueが構造体（例えば、Intやカスタム検証状態構造体）を返す場合、$property.errorCount += 1のような文は、一時的なコピーを変異させ、そのコピーはすぐに破棄されます。持続的な変異を可能にするためには、projectedValueが参照型を返すか、ラッパーがクラスベースのストレージでCoWを実装する必要があります。あるいは、間接アクセスを提供するBindingまたはミュータブルポインタを返すこともできます。初心者はしばしば、$propertyがラッパーの内部状態への可変アクセスを提供することを前提にし、Swiftの値セマンティクスを考慮しません。

合成されたドル記号プロパティのアクセス制御は元のプロパティのアクセスレベルとどのように相互作用するか？

コンパイラは、元のプロパティと同じアクセス制御を持つ$プレフィックスプロパティを合成します。public @Wrapper var name: Stringと宣言すると、nameと$nameは両方ともpublicです。逆に、privateプロパティはprivate投影値を生成します。候補者はしばしば、ラップされた値を公開しながら投影値を内部またはプライベートに保とうとしますが、これは現在のSwiftバージョンでは不可能です。この作業周回は、プロパティをprivateにし、ラップされた値を明示的な計算プロパティを通じて公開しながら、投影値を制限されたままにすることを要求します。

単一のプロパティラッパーが複数の異なる投影を公開することはできるか、そしてその人間工学的な影響は何か？

Swiftは、ラッパーあたり1つのprojectedValueプロパティのみを厳格に許可します。ただし、そのプロパティは複数の値を含むタプル、構造体、または列挙型を返すことができます（例：projectedValue: (Binding<T>, ValidationError?, Bool)）。人間工学的なトレードオフとして、その場合は、コンポーネントにアクセスするためにドット構文を必要とします（$property.0, $property.isValid）、可読性が低下します。候補者の中には、複数のprojectedValueプロパティを宣言したり、同じプロパティに複数のプロパティラッパーを適用したりする（チェイニング）ことを試みる者もいます。チェイニングはサポートされていますが、複雑な初期化セマンティクスと不透明な型推論の問題を引き起こします。複数の投影に対する推奨アプローチは、型安全性を保ちながら名前付きプロパティを持つ専用の投影構造体を返すことです。