Swift 5.1 ha introdotto i wrapper di proprietà tramite SE-0258 per eliminare il fastidio ripetitivo degli accessor. Il requisito di projectedValue è stato progettato per esporre superfici API secondarie—come il Binding di SwiftUI o gli stati di validazione—oltre al valore incapsulato stesso. Questa funzionalità consente agli sviluppatori di accedere a metadati o proiezioni utilizzando la sintassi del prefisso $.
Il problema sorge perché Swift deve trasformare la sintassi dichiarativa in SIL (Swift Intermediate Language) valido senza introdurre conflitti di nome o violare il controllo degli accessi. Il compilatore deve sintetizzare uno storage che mantenga la semantica del valore per la proprietà incapsulata mentre potenzialmente espone semantiche di riferimento attraverso la proiezione, il tutto assicurandosi che l'identificatore con prefisso $ non confligga con i membri definiti dall'utente.
La soluzione implica una desugarizzazione da sorgente a sorgente. Per una proprietà dichiarata come @Wrapper var property: T, il compilatore genera tre membri distinti. In primo luogo, una variabile di archiviazione privata _property di tipo Wrapper<T>. In secondo luogo, una proprietà calcolata property che inoltra le operazioni di get/set a _property.wrappedValue. In terzo luogo, una proprietà calcolata $property che restituisce _property.projectedValue. La proprietà con prefisso $ eredita il controllo degli accessi della dichiarazione originale e il compilatore impone che projectedValue esista quando si utilizza la sintassi $.
@propertyWrapper struct Validating<T> { var wrappedValue: T var projectedValue: ValidationState<T> init(wrappedValue: T) { self.wrappedValue = wrappedValue self.projectedValue = ValidationState(value: wrappedValue) } } // Desugara in: struct Form { private var _username: Validating<String> var username: String { get { _username.wrappedValue } set { _username.wrappedValue = newValue } } var $username: ValidationState<String> { get { _username.projectedValue } } }
Stavamo architettando un'applicazione di inserimento dati medici in cui ciascun campo doveva tenere traccia sia del suo valore attuale che di una complessa cronologia di validazione, inclusi errori precedenti e timestamp di correzione. La sfida richiedeva di esporre due percorsi dati distinti da un'unica astrazione di proprietà: la stringa grezza per il campo di testo dell'interfaccia utente e la cronologia di validazione per l'analisi e la visualizzazione degli errori.
Il primo approccio considerato è stato quello di mantenere un dizionario parallelo che mappasse i nomi delle proprietà a oggetti ValidationHistory. Questo offriva flessibilità nell'archiviazione ma introduceva API di tipo stringoso che si rompono durante il refactoring e richiedevano la sincronizzazione manuale tra il dizionario e i valori effettivi delle proprietà. Il rischio di desincronizzazione che portava a visualizzazioni di errore obsolete era inaccettabilmente alto per i dati medici.
Il secondo approccio comportava la creazione di una struttura wrapper che contenesse sia il valore che la cronologia, utilizzando quel tipo composto come tipo di proprietà. Sebbene fosse sicuro per i tipi, inquinava il modello di dominio con preoccupazioni di validazione e costringeva ogni sito di accesso a gestire lo sblocco, sconfiggendo lo scopo della separazione dell'architettura pulita tra l'interfaccia utente e la logica aziendale.
Il terzo approccio ha utilizzato un wrapper di proprietà personalizzato @Validated con un projectedValue che restituisce un tipo di riferimento ValidationHistory. Questo ha racchiuso internamente la sincronizzazione mentre esponeva $fieldName per l'accesso alla cronologia. Abbiamo scelto questo perché manteneva la semantica CoW (Copy-on-Write) per il valore della stringa incapsulata mentre forniva un'identità di riferimento stabile per la cronologia di validazione, garantendo che i componenti dell'interfaccia utente potessero osservare le modifiche senza overhead di copia.
Il risultato ha eliminato un'intera classe di bug di sincronizzazione e ha ridotto il codice relativo alla validazione del 35%. La sintassi $ ha fornito una scoperta intuitiva per i programmatori junior e l'applicazione delle regole di compilazione ha impedito l'esposizione accidentale di dettagli di implementazione tra i confini del modulo.
Perché le mutazioni a un projectedValue di tipo valore non persistono quando vengono effettuate tramite il prefisso di dollaro?
Quando il wrapper di proprietà è una struttura, il getter di projectedValue restituisce una copia del valore. Se projectedValue restituisce una struttura (come un Int o una struttura di stato di validazione personalizzata), istruzioni come $property.errorCount += 1 modificano una copia temporanea che viene immediatamente scartata. Per abilitare mutazioni persistenti, projectedValue deve restituire un tipo di riferimento o il wrapper deve implementare CoW con uno storage basato su classe. In alternativa, restituire un Binding o un puntatore mutabile che fornisca indirezione. I principianti suppongono spesso che $property fornisca accesso mutabile allo stato interno del wrapper senza considerare le semantiche di valore di Swift.
Come interagisce il controllo degli accessi della proprietà sintetizzata con prefisso di dollaro con il livello di accesso della proprietà originale?
Il compilatore sintetizza la proprietà con prefisso $ con un controllo degli accessi identico a quello della proprietà originale. Se dichiari public @Wrapper var name: String, sia name che $name sono public. Al contrario, le proprietà private generano valori proiettati private. I candidati tentano spesso di rendere il valore incapsulato pubblico mentre mantengono il valore proiettato interno o privato, il che è impossibile nelle attuali versioni di Swift. La soluzione richiede di rendere la proprietà private e di esporre il valore incapsulato attraverso una proprietà calcolata esplicita, mentre il valore proiettato rimane ristretto.
Può un singolo wrapper di proprietà esporre più proiezioni distinte e quali sono le implicazioni ergonomiche?
Swift consente rigorosamente solo una proprietà projectedValue per wrapper. Tuttavia, quella proprietà può restituire una tupla, una struttura o un enum contenente più valori (ad esempio, projectedValue: (Binding<T>, ValidationError?, Bool)). Il compromesso ergonomico è che $property richiede quindi la sintassi a punto per accedere ai componenti ($property.0, $property.isValid), riducendo la leggibilità. Alcuni candidati tentano di dichiarare più proprietà projectedValue o di applicare più wrapper di proprietà alla stessa proprietà (catena). Sebbene la catena sia supportata, crea semantiche di inizializzazione complesse e problemi di inferenza di tipo opaca. L'approccio raccomandato per più proiezioni è restituire una struttura di proiezione dedicata con proprietà denominate, preservando la sicurezza dei tipi accettando al contempo l'overhead di sintassi.