Swift 5.1 a introduit les wrappers de propriété via SE-0258 pour éliminer le boilerplate d'accès répétitif. L'exigence de projectedValue a été conçue pour exposer des surfaces d'API secondaires, telles que le Binding de SwiftUI ou les états de validation, au-delà de la valeur encapsulée elle-même. Cette fonctionnalité permet aux développeurs d'accéder à des métadonnées ou des projections en utilisant la syntaxe de préfixe $.
Le problème survient parce que Swift doit transformer la syntaxe déclarative en SIL valide (Swift Intermediate Language) sans introduire de conflits de noms ni briser le contrôle d'accès. Le compilateur doit synthétiser un stockage qui maintient les sémantiques de valeur pour la propriété enveloppée tout en exposant potentiellement des sémantiques de référence à travers la projection, tout en garantissant que l'identifiant préfixé par $ ne conflige pas avec les membres définis par l'utilisateur.
La solution implique un désaccharinage source-à-source. Pour une propriété déclarée comme @Wrapper var property: T, le compilateur génère trois membres distincts. D'abord, une variable de stockage privée _property de type Wrapper<T>. Deuxièmement, une propriété calculée property qui transfère les opérations get/set à _property.wrappedValue. Troisièmement, une propriété calculée $property qui retourne _property.projectedValue. La propriété préfixée par $ hérite du contrôle d'accès de la déclaration originale, et le compilateur impose que projectedValue existe lorsque la syntaxe $ est utilisée.
@propertyWrapper struct Validating<T> { var wrappedValue: T var projectedValue: ValidationState<T> init(wrappedValue: T) { self.wrappedValue = wrappedValue self.projectedValue = ValidationState(value: wrappedValue) } } // Désaccharine à : struct Form { private var _username: Validating<String> var username: String { get { _username.wrappedValue } set { _username.wrappedValue = newValue } } var $username: ValidationState<String> { get { _username.projectedValue } } }
Nous architecturions une application d'entrée de données médicales où chaque champ devait suivre à la fois sa valeur actuelle et un historique de validation complexe, y compris les erreurs précédentes et les horodatages de correction. Le défi nécessitait d'exposer deux chemins de données distincts à partir d'une seule abstraction de propriété : la chaîne brute pour le champ de texte de l'interface utilisateur, et l'historique de validation pour l'analyse et l'affichage des erreurs.
La première approche envisagée a été de maintenir un dictionnaire parallèle mappant les noms de propriétés aux objets ValidationHistory. Cela offrait une flexibilité de stockage mais introduisait des APIs de type stringly qui se brisaient lors du refactoring et nécessitaient une synchronisation manuelle entre le dictionnaire et les valeurs de propriété réelles. Le risque de désynchronisation entraînant un affichage d'erreurs obsolètes était inacceptablement élevé pour les données médicales.
La deuxième approche impliquait de créer une structure de wrapper contenant à la fois la valeur et l'historique, puis d'utiliser ce type composé comme type de propriété. Bien que sûr en termes de types, cela polluait le modèle de domaine avec des préoccupations de validation et forçait chaque site d'accès à gérer le désenveloppement, contrecarrant ainsi l'objectif de séparation claire entre l'architecture de l'interface utilisateur et la logique métier.
La troisième approche utilisait un wrapper de propriété @Validated personnalisé avec un projectedValue retournant un type de référence ValidationHistory. Cela encapsulait la synchronisation en interne tout en exposant $fieldName pour l'accès à l'historique. Nous avons choisi cela car cela maintenait les sémantiques CoW (Copy-on-Write) pour la valeur de chaîne encapsulée tout en assurant une identité de référence stable pour l'historique de validation, garantissant que les composants de l'interface utilisateur pouvaient observer les changements sans surcoût de copie.
Le résultat a éliminé toute une classe de bogues de synchronisation et réduit le code lié à la validation de 35 %. La syntaxe $ a fourni une découvrabilité intuitive pour les développeurs juniors, et l'application stricte des règles de compilation a empêché l'exposition accidentelle des détails d'implémentation entre les frontières des modules.
Pourquoi les mutations d'un projectedValue de type valeur ne persistent-elles pas lorsqu'elles sont accessibles via le préfixe dollar ?
Lorsque le wrapper de propriété est une structure, le getter projectedValue retourne une copie de la valeur. Si projectedValue retourne une structure (comme un Int ou une structure d'état de validation personnalisée), des instructions comme $property.errorCount += 1 mutent une copie temporaire qui est immédiatement rejetée. Pour permettre des mutations persistantes, le projectedValue doit retourner un type de référence, ou le wrapper doit implémenter CoW avec un stockage basé sur une classe. Alternativement, retourner un Binding ou un pointeur mutable qui fournit une indirection. Les débutants supposent souvent que $property fournit un accès mutable à l'état interne du wrapper sans tenir compte des sémantiques de valeur de Swift.
Comment le contrôle d'accès de la propriété préfixée par dollar synthétisée interagit-il avec le niveau d'accès de la propriété originale ?
Le compilateur synthétise la propriété préfixée par $ avec un contrôle d'accès identique à la propriété originale. Si vous déclarez public @Wrapper var name: String, les deux name et $name sont public. Inversement, les propriétés private génèrent des valeurs projetées private. Les candidats tentent souvent de rendre la valeur enveloppée publique tout en gardant la valeur projetée interne ou privée, ce qui est impossible dans les versions actuelles de Swift. La solution de contournement nécessite de rendre la propriété private et d'exposer la valeur enveloppée via une propriété calculée explicite, tandis que la valeur projetée reste restreinte.
Un seul wrapper de propriété peut-il exposer plusieurs projections distinctes, et quelles sont les implications ergonomiques ?
Swift permet strictement un seul projectedValue par wrapper. Cependant, cette propriété peut retourner un tuple, une structure ou une énumération contenant plusieurs valeurs (par exemple, projectedValue: (Binding<T>, ValidationError?, Bool)). Le compromis ergonomique est que $property nécessite alors une syntaxe pointée pour accéder aux composants ($property.0, $property.isValid), réduisant la lisibilité. Certains candidats essaient de déclarer plusieurs propriétés projectedValue ou d'appliquer plusieurs wrappers de propriété à la même propriété (chaînage). Bien que le chaînage soit pris en charge, cela crée des sémantiques d'initialisation complexes et des problèmes d'inférence de type opaques. L'approche recommandée pour plusieurs projections consiste à retourner une structure de projection dédiée avec des propriétés nommées, préservant la sécurité des types tout en acceptant la surcharge de syntaxe.