Swift 5.1 introdujo los envoltorios de propiedad a través de SE-0258 para eliminar el código repetitivo del accesorio. El requisito de projectedValue fue diseñado para exponer superficies de API secundarias—como el Binding de SwiftUI o los estados de validación—más allá del valor envuelto en sí. Esta característica permite a los desarrolladores acceder a metadatos o proyecciones utilizando la sintaxis de prefijo $.
El problema surge porque Swift debe transformar la sintaxis declarativa en SIL válido (Swift Intermediate Language) sin introducir colisiones de nombres o romper el control de acceso. El compilador necesita sintetizar almacenamiento que mantenga las semánticas de valor para la propiedad envuelta mientras expone potencialmente semánticas de referencia a través de la proyección, todo mientras asegura que el identificador con prefijo $ no entre en conflicto con miembros definidos por el usuario.
La solución implica la desazucarado de fuente a fuente. Para una propiedad declarada como @Wrapper var property: T, el compilador genera tres miembros distintos. Primero, una variable de almacenamiento privada _property de tipo Wrapper<T>. Segundo, una propiedad computada property que reenvía las operaciones de obtención/establecimiento a _property.wrappedValue. Tercero, una propiedad computada $property que devuelve _property.projectedValue. La propiedad con prefijo $ hereda el control de acceso de la declaración original, y el compilador hace cumplir que projectedValue existe cuando se utiliza la sintaxis $.
@propertyWrapper struct Validating<T> { var wrappedValue: T var projectedValue: ValidationState<T> init(wrappedValue: T) { self.wrappedValue = wrappedValue self.projectedValue = ValidationState(value: wrappedValue) } } // Se desazucara a: struct Form { private var _username: Validating<String> var username: String { get { _username.wrappedValue } set { _username.wrappedValue = newValue } } var $username: ValidationState<String> { get { _username.projectedValue } } }
Estábamos diseñando una aplicación de entrada de datos médicos donde cada campo necesitaba rastrear tanto su valor actual como una historia de validación compleja que incluía errores previos y marcas de tiempo de corrección. El desafío requería exponer dos rutas de datos distintas desde una única abstracción de propiedad: la cadena cruda para el campo de texto de la interfaz de usuario y la historia de validación para análisis y visualización de errores.
El primer enfoque considerado fue mantener un diccionario paralelo que mapeaba nombres de propiedades a objetos ValidationHistory. Esto ofrecía flexibilidad en el almacenamiento, pero introducía APIs de tipo basado en cadenas que se rompían durante la refactorización y requerían una sincronización manual entre el diccionario y los valores reales de las propiedades. El riesgo de desincronización que llevara a visualizaciones de errores obsoletas era inaceptablemente alto para los datos médicos.
El segundo enfoque involucró crear una estructura envoltorio que contenía tanto el valor como la historia, usando ese tipo compuesto como el tipo de propiedad. Si bien es seguro en cuanto a tipos, contaminaba el modelo de dominio con preocupaciones de validación y forzaba a cada sitio de acceso a manejar la desenvuelta, socavando el propósito de la separación de la arquitectura limpia entre la UI y la lógica empresarial.
El tercer enfoque utilizó un envoltorio de propiedad @Validated personalizado con un projectedValue que devolvía un tipo de referencia ValidationHistory. Esto encapsuló la sincronización internamente mientras exponía $fieldName para el acceso a la historia. Elegimos esto porque mantenía las semánticas de CoW (Copiar al escribir) para el valor de cadena envuelto mientras proveía una identidad de referencia estable para la historia de validación, asegurando que los componentes de la UI pudieran observar cambios sin sobrecarga de copia.
El resultado eliminó toda una clase de errores de sincronización y redujo el código relacionado con la validación en un 35%. La sintaxis $ proporcionó una descubribilidad intuitiva para desarrolladores junior, y la imposición en tiempo de compilación evitó la exposición accidental de detalles de implementación a través de límites de módulo.
¿Por qué las mutaciones a un projectedValue de tipo valor no persisten cuando se accede a través del prefijo de signo de dólar?
Cuando el envoltorio de propiedad es una estructura, el getter de projectedValue devuelve una copia del valor. Si projectedValue devuelve una estructura (como un Int o una estructura de estado de validación personalizada), declaraciones como $property.errorCount += 1 mutan una copia temporal que se descarta inmediatamente. Para habilitar mutaciones persistentes, projectedValue debe devolver un tipo de referencia, o el envoltorio debe implementar CoW con un almacenamiento basado en clase. Alternativamente, devolver un Binding o puntero mutable que proporcione indirección. Los principiantes a menudo asumen que $property proporciona acceso mutable al estado interno del envoltorio sin considerar las semánticas de valor de Swift.
¿Cómo interactúa el control de acceso de la propiedad sintetizada de signo de dólar con el nivel de acceso de la propiedad original?
El compilador sintetiza la propiedad con prefijo $ con un control de acceso idéntico al de la propiedad original. Si declaras public @Wrapper var name: String, tanto name como $name son public. Inversamente, las propiedades private generan valores proyectados private. Los candidatos a menudo intentan hacer que el valor envuelto sea público mientras mantienen el valor proyectado interno o privado, lo que es imposible en las versiones actuales de Swift. La solución requiere hacer que la propiedad sea private y exponer el valor envuelto a través de una propiedad computada explícita, mientras que el valor proyectado permanece restringido.
¿Puede un solo envoltorio de propiedad exponer múltiples proyecciones distintas, y cuáles son las implicaciones ergonómicas?
Swift estrictamente permite solo una propiedad projectedValue por envoltorio. Sin embargo, esa propiedad puede devolver una tupla, estructura o enumeración que contenga múltiples valores (por ejemplo, projectedValue: (Binding<T>, ValidationError?, Bool)). La compensación ergonómica es que $property requiere entonces sintaxis de punto para acceder a los componentes ($property.0, $property.isValid), reduciendo la legibilidad. Algunos candidatos intentan declarar múltiples propiedades projectedValue o aplicar múltiples envoltorios de propiedades a la misma propiedad (encadenamiento). Si bien el encadenamiento está soportado, crea semánticas de inicialización complejas y problemas de inferencia de tipos opacos. El enfoque recomendado para múltiples proyecciones es devolver una estructura de proyección dedicada con propiedades nombradas, preservando la seguridad de tipos mientras se acepta la sobrecarga de sintaxis.