Swift wprowadził budownicze wyników (pierwotnie nazywane budowniczymi funkcji) w wersji 5.1, aby umożliwić deklaratywną składnię dla bibliotek takich jak SwiftUI. Wcześniej tworzenie hierarchicznych struktur danych wymagało głęboko zagnieżdżonych wywołań inicjalizatora, które były wizualnie szumne i trudne do utrzymania. Funkcja była inspirowana bibliotekami łączników parserów oraz monadami programowania funkcyjnego, dostosowanymi do statycznego systemu typów Swift, zachowując jednocześnie znajomość składni imperatywnej.
Programiści potrzebowali sposobu na pisanie sekwencyjnych instrukcji, które konstruowałyby złożone wartości, nie rezygnując z bezpieczeństwa typów w czasie kompilacji Swift ani nie wprowadzając narzutu czasowego. Głównym wyzwaniem było wsparcie konstrukcji kontrolnych, takich jak instrukcje if i pętle for w tych konstrukcjach, gdzie różne gałęzie mogłyby produkować różne typy, które musiały być zjednoczone w jeden typ wyniku. Proste używanie tablic typów egzystencjalnych straciłoby informacje o konkretnych typach i wymusiłoby dynamiczną dispatch, podważając krytyczne dla wydajności ścieżki kodu.
Komplilator Swift dokonuje transformacji źródło do źródła w fazie analizy semantycznej, przepisując ciało zamknięcia budowniczego wyników w szereg statycznych wywołań metod na typie budowniczego. Sekwencyjne instrukcje stają się argumentami funkcji buildBlock, a warunkowe konstrukcje desugarują się do wywołań buildEither(first:) i buildEither(second:), a opcjonalne gałęzie używają buildOptional. Ta transformacja ma miejsce przed sprawdzaniem typów, co pozwala kompilatorowi zweryfikować, że skomponowane typy odpowiadają oczekiwanemu typowi wyniku, generując wydajny kod liniowy odpowiadający ręcznym zagnieżdżonym wywołaniom.
@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" } }
Zespół back-endowy potrzebował skonstruować potoki zapytań do bazy danych za pomocą płynnego interfejsu. Chcieli składni, w której programiści mogliby wymieniać operacje pionowo, zamiast łańcuchować metody za pomocą kropek, przy zachowaniu weryfikacji zgodności schematu w czasie kompilacji.
Najpierw rozważali użycie tradycyjnego łańcuchowania metod, gdzie każda operacja zwracałaby zmodyfikowany obiekt Query. To podejście działało w przypadku prostych liniowych potoków, ale stało się nieporęczne przy warunkowym dodawaniu filtrów lub łączeń, wymagając zmiennych tymczasowych i złożonych ekspresji trójargumentowych, aby utrzymać łańcuch. Wymusiło to także, aby wszystkie typy pośrednie były takie same, uniemożliwiając optymalizacje specyficzne dla etapu.
Inną opcją było przyjęcie tablicy zamknięć bazujących na modyfikatorach [(Query) -> Query]. To pozwoliło na pożądaną składnię pionową, ale całkowicie zatarło informacje o typach na każdym kroku, uniemożliwiając weryfikację w czasie kompilacji istnienia kolumn lub niezgodności typów. Testy wydajnościowe pokazały, że wprowadziło to 15% narzutu czasowego z powodu niemożności użycia inliningu dla zamknięć transformacyjnych.
Zespół zaimplementował niestandardowego budowniczego wyników @QueryBuilder. Zdefiniowali przeciążone metody buildBlock, aby akceptować heterogeniczne etapy potoku i łączyć je w typowaną krotkę, buildEither, aby obsługiwać warunkowe klauzule WHERE bez zacierania typów, oraz buildArray dla operacji JOIN generowanych przez pętle for. To zachowało pionową deklaratywną składnię, jednocześnie utrzymując zerowe koszty abstrakcji, pozwalając optymalizatorowi LLVM na inlining całej konstrukcji potoku. Kod definiujący zapytania stał się krótszy o 50%, a niezgodności schematu były wychwytywane w czasie kompilacji, a nie podczas testów integracyjnych.
Jak kompilator desugaruje instrukcję switch w obrębie budowniczego wyników, gdy różne przypadki zwracają różne konkretne typy?
Kompilator przekształca switch w binarne drzewo zagnieżdżonych wywołań buildEither, wymagając od sprawdzacza typów zjednoczenia wszystkich gałęzi w jednolity typ. Jeśli przypadki zwracają różne typy (np. Text vs Image w SwiftUI), kompilacja kończy się niepowodzeniem, chyba że budowniczy zapewnia wymazanie typów. Kandydaci często zakładają, że switch otrzymuje specjalne zarządzanie wielokierunkowym dispatch, ale w rzeczywistości przechodzi przez binarne decyzje (pierwszy przypadek vs reszta). Rozwiązanie wymaga albo zapewnienia, że wszystkie przypadki zwracają ten sam konkretny typ, albo implementacji buildExpression, aby owinąć wartości w egzystencjalny kontener, taki jak AnyView, chociaż to poświęca możliwości optymalizacji statycznej.
Dlaczego dodanie kontroli @available wewnątrz budowniczego wyników wymaga specjalnej obsługi za pomocą buildLimitedAvailability?
Gdy budowniczy wyników zawiera kod owinięty w kontrole dostępności (np. if #available(iOS 15, *)), kompilator nie może zagwarantować, że komponenty w zabezpieczonym bloku istnieją na wszystkich docelowych wersjach. Bez buildLimitedAvailability sprawdzacz typów nie ma szansy, ponieważ próbuje zweryfikować kod zabezpieczony dostępnością względem minimalnego docelowego systemu. Ta metoda działa jako filtr w czasie kompilacji, pozwalając budowniczemu na zastąpienie miejsca lub pustej wartości, gdy celuje w starsze wersje OS. Kandydaci nie dostrzegają, że to zapobiega błędom łączenia „symbol nie znaleziony” poprzez zapewnienie, że niedostępne ścieżki kodu są w pełni usuwane typowo lub zastępowane przed generowaniem binariów.
Jaka jest precyzyjna różnica między buildExpression a buildBlock, i kiedy implementacja buildExpression jest konieczna dla bezpieczeństwa typów?
buildBlock łączy wiele już przekształconych komponentów w ostateczny rezultat, podczas gdy buildExpression jest opcjonalnym hakiem, który przekształca pojedyncze wyrażenia przed ich przekazaniem do buildBlock. Kandydaci często pomijają, że buildExpression umożliwia wczesne wymazanie typów na poziomie wyrażeń, pozwalając na zjednoczenie heterogenicznych typów przed ich połączeniem. Na przykład, SwiftUI's ViewBuilder używa buildExpression, aby niejawnie owinąć widoki w AnyView tylko wtedy, gdy to konieczne, lub aby zastosować modyfikatory widoków. Bez zrozumienia tej różnicy, deweloperzy nie mogą wdrożyć budowniczych, którzy elegancko radzą sobie z niedopasowaniami typów między sekwencyjnymi instrukcjami bez zmuszania użytkownika do ręcznego rzutowania każdego wyrażenia.