Swift는 5.1 버전에서 결과 빌더(원래는 함수 빌더로 불림)를 도입하여 SwiftUI와 같은 라이브러리에 선언적 구문을 사용할 수 있게 하였습니다. 이 전에는 계층적 데이터 구조를 생성하기 위해 깊이 중첩된 초기화자 호출이 필요했으며, 이는 시각적으로 시끄럽고 유지 관리가 어려웠습니다. 이 기능은 파서 조합기 라이브러리와 함수형 프로그래밍 모나드에서 영감을 받아 Swift의 정적 타입 시스템에 적합하도록 조정되었고, 명령형 구문 친숙성을 유지하였습니다.
개발자들은 복잡한 값을 구성하는 순차적인 문을 작성할 수 있는 방법이 필요했습니다. 그러나 이는 Swift의 컴파일 타임 타입 안전성을 희생하지 않거나 런타임 오버헤드를 도입하지 않도록 해야 했습니다. 중앙 도전 과제는 조건문 및 for 루프와 같은 제어 흐름 구조를 지원하는 것이었습니다. 이러한 구조에서 서로 다른 분기가 서로 다른 유형을 생성할 수 있으며, 이들 유형은 단일 결과 유형으로 통합되어야 합니다. 단순히 실존 타입의 배열을 사용하는 것은 구체적인 유형 정보를 잃게 하고 동적 디스패치를 강요하므로, 성능에 중요한 코드 경로를 약화시킬 수 있습니다.
Swift 컴파일러는 의미 분석 단계에서 소스에서 소스로의 변환을 수행하여 결과 빌더 클로저 본문을 빌더 유형에 대한 일련의 정적 메서드 호출로 다시 작성합니다. 순차 문장은 buildBlock의 인수로 변환되고, 조건문은 buildEither(first:) 및 buildEither(second:) 호출로 디저그되며, 선택적 분기는 buildOptional을 사용합니다. 이 변환은 타입 검사가 이루어지기 전에 발생하므로, 컴파일러는 조합된 유형이 예상 반환 유형과 일치하는지 확인할 수 있으며, 수동 중첩 호출에 해당하는 효율적인 인라인 코드를 생성합니다.
@resultBuilder struct MyBuilder { static func buildBlock<T1, T2>(_ t1: T1, _ t2: T2) -> (T1, T2) { (t1, t2) } static func buildOptional<T>(_ component: T?) -> T? { component } static func buildEither<T>(first: T) -> T { first } static func buildEither<T>(second: T) -> T { second } } @MyBuilder func build() -> (Int, String?) { 42 if Bool.random() { "hello" } }
백엔드 팀은 유창한 인터페이스를 사용하여 데이터베이스 쿼리 파이프라인을 구성해야 했습니다. 그들은 개발자들이 점으로 메서드를 연결하는 대신 수직으로 작업을 나열할 수 있는 구문을 원했습니다. 또한 스키마 호환성에 대한 컴파일 타임 검증을 유지하고 싶었습니다.
그들은 처음에 각 작업이 수정된 Query 객체를 반환하는 전통적인 메서드 체인을 사용하는 것을 고려했습니다. 이 접근 방식은 간단한 선형 파이프라인에서는 잘 작동했지만, 필터 또는 조인을 조건부로 추가할 때 복잡해져 임시 변수를 사용해야 하고 체인을 유지하기 위해 복잡한 3항 표현식을 사용해야 했습니다. 또한 모든 중간 유형이 동일해야 하므로 특정 단계 최적화를 방해했습니다.
또 다른 옵션은 클로저 기반 수식어의 배열 [(Query) -> Query]를 허용하는 것이었습니다. 이것은 원하는 수직 구문을 가능하게 했지만 각 단계에서 유형 정보를 완전히 없애서 열 존재 여부나 유형 불일치를 컴파일 타임에 검증할 수 없게 했습니다. 벤치마크 결과는 이로 인해 변환 클로저를 인라인할 수 없어서 15%의 런타임 오버헤드가 발생했다는 것을 보여주었습니다.
팀은 사용자 정의 @QueryBuilder 결과 빌더를 구현했습니다. 그들은 이질적인 파이프라인 단계를 수용하고 이를 typed 튜플로 결합하는 오버로드된 buildBlock 메서드를 정의했으며, 유형을 삭제하지 않고 조건부 WHERE 절을 처리하는 buildEither, 그리고 for 루프에서 생성된 JOIN 작업을 위한 buildArray를 정의했습니다. 이는 수직의 선언적 구문을 보존하면서 제로 비용 추상화를 유지할 수 있게 하여 LLVM 최적화 도구가 전체 파이프라인 구성을 인라인할 수 있게 했습니다. 쿼리 정의 코드가 50% 짧아졌고, 스키마 불일치가 통합 테스트가 아닌 컴파일 타임에 잡혔습니다.
스위프트의 결과 빌더 내에서 서로 다른 경우가 서로 다른 구체적 타입을 반환할 때 컴파일러는 switch문을 어떻게 디저그합니까?
컴파일러는 switch를 중첩된 buildEither 호출의 이진 트리로 변환하여 모든 분기를 단일 타입으로 통합해야 합니다. 만약 경우가 서로 다른 타입을 반환하면(예: SwiftUI에서의 Text와 Image), 빌더가 타입 삭제를 제공하지 않는 한 컴파일이 실패합니다. 후보자들은 종종 switch가 특별한 다중 경로 디스패치 처리를 받는다고 가정하지만, 실제로는 이진 결정(첫 번째 경우 대 나머지)을 통해 캐스케이드됩니다. 이 솔루션은 모든 경우가 동일한 구체적 유형을 반환하도록 하거나 값을 AnyView와 같은 실존 컨테이너에 래핑하는 buildExpression을 구현해야 합니다. 이 경우 정적 최적화 기회를 희생하게 됩니다.
결과 빌더 내부에 @available 체크를 추가하려면 buildLimitedAvailability를 통해 특별한 처리가 필요합니까?
결과 빌더 내부에 가용성 체크로 래핑된 코드(예: if #available(iOS 15, *))가 포함되면, 컴파일러는 보호 블록 내의 구성 요소가 모든 배포 대상에서 존재한다고 보장할 수 없습니다. buildLimitedAvailability 없이, 타입 검사기가 최소 배포 대상에 대해 가용성 보호 코드를 확인하려고 시도하므로 실패합니다. 이 방법은 컴파일 타임 필터로 작용하여 더 오래된 OS 버전을 타겟팅할 때 빌더가 자리 표시자 또는 빈 값을 대체하도록 합니다. 후보자들은 이로 인해 모든 사용 불가능한 코드 경로가 이진 생성 전에 완전히 타입 삭제되거나 교체되도록 하여 "심볼을 찾을 수 없음"의 링크 타임 오류를 방지한다는 것을 놓치게 됩니다.
buildExpression과 buildBlock의 정확한 차이는 무엇입니까? 타입 안전성을 위해 buildExpression을 구현해야 하는 이유는 무엇인가요?
buildBlock은 이미 변환된 여러 구성 요소를 최종 결과로 결합하지만, buildExpression은 선택적 훅으로서 개별 표현식을 buildBlock에 전달되기 전에 변환합니다. 후보자들은 종종 buildExpression이 표현 수준에서 조기 타입 삭제를 가능하게 하여 이질적 유형을 조합하기 전에 통합할 수 있도록 해준다는 점을 놓칩니다. 예를 들어, SwiftUI의 ViewBuilder는 필요할 때만 보기들을 AnyView로 암시적으로 래핑하기 위해 buildExpression을 사용합니다. 이 구별을 이해하지 못하면, 개발자들은 사용자가 모든 표현식을 수동으로 캐스팅하도록 강요하지 않고도 순차 문 간의 유형 불일치를 우아하게 처리하는 빌더를 구현할 수 없습니다.