Swift 5.1은 SE-0258을 통해 속성 래퍼를 도입하여 반복적인 접근자 보일러플레이트를 제거했습니다. projectedValue 요구 사항은 래핑된 값 자체를 넘어서 SwiftUI의 Binding이나 유효성 검사 상태와 같은 2차 API 면을 노출하도록 설계되었습니다. 이 기능은 개발자가 $ 접두사 구문을 사용하여 메타데이터나 프로젝션에 접근할 수 있게 합니다.
문제는 Swift가 선언적 구문을 유효한 SIL(스위프트 중간 언어)로 변환해야 하지만 이름 충돌을 일으키거나 접근 제어를 깨뜨리지 않아야 한다는 점입니다. 컴파일러는 래핑된 속성의 값 의미론을 유지하면서 잠재적으로 프로젝션을 통해 참조 의미론을 노출하는 저장소를 합성해야 합니다. 이 모든 작업은 $ 접두사 식별자가 사용자 정의 멤버와 충돌하지 않도록 보장해야 합니다.
해결책은 소스에서 소스로의 변환을 포함합니다. @Wrapper var property: T로 선언된 속성의 경우, 컴파일러는 세 가지 서로 다른 멤버를 생성합니다. 첫째, 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 텍스트 필드, 분석 및 오류 표시를 위한 유효성 검사 기록의 두 가지 별도 데이터 경로를 노출하는 것을 요구했습니다.
고려된 첫 번째 접근법은 속성 이름을 ValidationHistory 객체에 매핑하는 병렬 사전을 유지하는 것이었습니다. 이는 저장소의 유연성을 제공했지만 리팩토링 중에 깨지는 문자열 기반 API를 도입하고 사전과 실제 속성 값 간의 수동 동기화를 요구했습니다. 의료 데이터에 대한 비동기화의 위험이 너무 높았습니다.
두 번째 접근법은 값과 기록을 포함하는 래퍼 구조체를 만든 다음 그 복합 타입을 속성 타입으로 사용하는 것이었습니다. 이는 타입 안전성을 유지했지만 도메인 모델을 유효성 검사 문제로 오염시켰고 모든 접근 지점에서 언래핑을 처리하도록 강요하여 UI와 비즈니스 논리 간의 깔끔한 아키텍처 분리를 무산시켰습니다.
세 번째 접근법은 ValidationHistory 참조 타입을 반환하는 projectedValue를 가진 사용자 정의 @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는 엄격하게 래퍼당 하나의 projectedValue 속성만 허용합니다. 그러나 그 속성은 여러 값을 포함하는 튜플, 구조체 또는 열거형을 반환할 수 있습니다(예: projectedValue: (Binding<T>, ValidationError?, Bool)). 인체 공학적 절충안은 $property가 구성 요소에 접근하기 위해 점 구문($property.0, $property.isValid)을 요구하므로 가독성이 감소합니다. 일부 후보자들은 여러 개의 projectedValue 속성을 선언하거나 동일한 속성에 여러 속성 래퍼를 적용하려고 시도합니다(체이닝). 체이닝은 지원되지만 복잡한 초기화 의미론과 불투명한 유형 추론 문제를 일으킵니다. 여러 프로젝션을 위한 권장 접근법은 명명된 속성으로 전용 프로젝션 구조체를 반환하는 것으로, 구문 오버헤드를 수용하면서 타입 안전성을 유지합니다.