Przed Swift 5.9, programiści napotykali znaczące ograniczenia ekspresyjne podczas pisania kodu ogólnego, który działał na heterogenicznych kolekcjach typów. Funkcje wymagające zmiennej liczby argumentów o odrębnych, zachowanych typach były zmuszone uciekać się do usuwania typów za pomocą Any lub kontenerów egzystencjalnych (any P), poświęcając bezpieczeństwo w czasie kompilacji i narażając na narzuty związane z alokacją w stercie. Wprowadzenie Parameter Packs (SE-0393, SE-0398 i SE-0399) wprowadziło wariantowe generiki do Swift, umożliwiając językowi wyrażanie wzorców, które wcześniej wymagały metaprogramowania szablonów w C++ lub wariantowych cech w Rust. Ta ewolucja rozwiązała podstawowe luki w programowaniu ogólnym, umożliwiając bezpieczne typowo, zero-kosztowe abstrakcje nad heterogenicznymi danymi bez ręcznego generowania przeciążeń.
Głównym wyzwaniem było wdrożenie mechanizmu, który mógłby przyjmować dowolną liczbę argumentów ogólnych—każdy potencjalnie o odrębnym typie—z jednoczesnym zachowaniem informacji o typie statycznym przez łańcuch wywołań. Rozwiązania sprzed wprowadzenia pakietów parametrów, używające [Any], wymagały rzutowania w czasie wykonywania i nie zachowały relacji typów, uniemożliwiając optymalizacje kompilatora, takie jak inline i wyspecjalizowane przesyłanie. Z drugiej strony, ręczne generowanie przeciążeń dla atrybutów od 1 do N (np. <T1>, <T1, T2>, <T1, T2, T3>) powodowało nadmiarowy kod binarny i nakładało arbitralne ograniczenia na liczbę argumentów. Rozwiązanie musiało wspierać iterację pakietów w czasie kompilacji, w którym kompilator generuje zmonomorfizowany kod specyficzny dla podpisu typu każdego miejsca wywołania, bez wprowadzania narzutów związanych z pakowaniem w czasie wykonywania ani indykcji tabeli świadków dla prostych typów wartości.
Swift implementuje pakiety parametrów poprzez rozszerzenie pakietów, traktując wzorzec repeat each T jako szablon w czasie kompilacji do generowania kodu. Gdy funkcja deklaruje pakiet parametrów typu <each T> i akceptuje pakiet wartości repeat each T, kompilator wykonuje monomorfizację w miejscu wywołania, rozwijając ciało ogólne w konkretny kod dla każdego elementu w pakiecie. To różni się od jednorodnych wariantów (np. Int...), ponieważ każdy element zachowuje swoją unikalną tożsamość typu. Słowo kluczowe repeat sygnalizuje etap generacji SIL (Swift Intermediate Language), że następne wyrażenie powinno zostać zdublowane dla każdego elementu pakietu, z odpowiednimi zamiennikami typów. Ta transformacja eliminuje pakowanie, ponieważ typy wartości pozostają na stosie w swoim konkretnym układzie, a wywołania funkcji są przesyłane statycznie, bez nadmiernych nakładów na kontenery egzystencjalne.
// Funkcja przyjmująca heterogeniczny pakiet parametrów func describeValues<each T>(_ values: repeat each T) { // Kompilator rozwija tę pętlę w czasie kompilacji repeat print("Typ: \(type(of: each values)), Wartość: \(each values)") } // Użycie generuje wyspecjalizowany kod równoważny: // describeValues(Int, String, Double) describeValues(42, "Swift", 3.14)
Nasz zespół projektował framework pipeline z danymi o wysokiej wydajności dla iOS, w którym użytkownicy potrzebowali łączyć heterogeniczne kroki transformacji (np. DecodeJSON<T>, Validate<U>, Map<V>) w jeden wykres wykonania. Interfejs API wymagał funkcji pipeline, która przyjmuje dowolną liczbę tych kroków, każdy z odrębnymi typami wejściowymi i wyjściowymi, a jednocześnie utrzymuje wiedzę o przepływie danych w czasie kompilacji, aby umożliwić przebiegi optymalizacyjne.
Początkowo wdrożyliśmy przeciążenia dla od 1 do 6 argumentów ogólnych (np. func pipeline<T1, T2>(_: T1, _: T2)). To zachowało statyczne typy i pozwoliło LLVM na inline'ing całego łańcucha. Jednak to podejście było zbyt obszerne i niewydajne, wymagając setek linii niemal identycznego kodu. Sztucznie ograniczało użytkowników do sześciu kroków, a każdy dodatkowy atrybut znacznie zwiększał rozmiar binarny z powodu duplikacji kodu. Gdy wymagania zmieniły się na obsługę ośmiu kroków, wysiłek refaktoryzacji był znaczny.
Następnie spróbowaliśmy zdefiniować protokół AnyPipelineStep z typami skojarzeniowymi, a następnie użyć [any AnyPipelineStep] jako parametru. To wspierało nieograniczoną liczbę kroków, ale zmuszało każdy typ wartości (struktury zawierające dane dekodowane) do zaalokowanych w stercie kontenerów egzystencjalnych. Profilowanie wydajności ujawniło, że 30% czasu CPU spędzano w operacjach swift_retain i swift_release na tych pudełkach. Dodatkowo, kompilator nie mógł już optymalizować między granicami kroków, ponieważ skojarzone typy były usuwane, co wymagało dynamicznego rzutowania na każdym połączeniu.
Z Swift 5.9, zrefaktoryzowaliśmy interfejs API na func pipeline<each Step: PipelineStep>(steps: repeat each Step). To pozwoliło kompilatorowi generować unikalną specjalizację dla każdej odrębnej kompozycji pipeline napotkanej w kodzie źródłowym. Każdy krok zachował swój konkretny typ, co umożliwiło agresywne wstawianie i alokację stosu dla tymczasowych struktur danych. Słowo kluczowe repeat pozwoliło nam iterować po pakiecie, aby zweryfikować zgodność typów między sąsiadującymi krokami w czasie kompilacji.
Przyjęliśmy pakiety parametrów, ponieważ wyeliminowały ograniczenie arności bez poświęcania wydajności. W przeciwieństwie do egzystencji, pakiety zachowały ogólny sygnaturze dla optymalizatora Swift, co dało zero-kosztowe abstrakcje. Refaktoryzacja zmniejszyła rozmiar binarny frameworka o 35% w porównaniu do podejścia z przeciążeniem oraz poprawiła wydajność o 4x w porównaniu do podejścia egzystencjalnego. Programiści mogli teraz tworzyć pipeline o dowolnej długości z pełnym wsparciem autouzupełniania dla konkretnych typów wejściowych/wyjściowych każdego kroku, wychwytując niezgodności danych w czasie kompilacji, a nie podczas testów integracyjnych.
Kandydaci często zakładają, że ograniczenia pakietów zachowują się jak pojedyncze ograniczenia ogólne, ale Swift wymaga wyraźnych wzorców repeat w klauzulach where. Ograniczając każdy element pakietu T do przestrzegania Container z różnymi typami skojarzonymi Item, składnia staje się func process<each T: Container>(_ items: repeat each T) where repeat each T.Item: Equatable. Kompilator przeprowadza rozwiązywanie ograniczeń strukturalnych, rozwijając klauzulę where element po elemencie w całym pakiecie. Popularnym błędem jest próba użycia jednego ograniczenia dla typu skojarzonego dla całego pakietu, co nie działa, ponieważ każdy T.Item jest odrębnym typem. Zrozumienie, że ograniczenia pakietów generują koniunkcję wymagań dla każdego elementu, a nie pojedyncze zjednoczone ograniczenie, jest kluczowe do debugowania błędów wniosku.
Programiści często wierzą, że pakiety parametrów gwarantują zero-kosztowe abstrakcje w wszystkich kontekstach, ale przekroczenie granic ABI lub użycie nieprzezroczystych typów wynikowych może wymusić pakowanie. Konkretnie, gdy pakiet parametrów jest uchwycony w zamykającej funkcji przekazanej do funkcji w innym obszarze odporności (np. interfejs publicznej biblioteki), Swift może wygenerować instancję ogólną w czasie wykonywania z użyciem tabel świadków zamiast statycznej specjalizacji. Podobnie, zwracanie some Collection z wewnątrz iteracji pakietu zmusza kompilator do użycia kontenera egzystencjalnego, ponieważ konkretny typ zwracany zmienia się w zależności od elementu pakietu. To wpływa na układ pamięci, wprowadzając alokację w stercie dla wbudowanego bufora egzystencjalnego (trzy słowa) i dodając indykcję przez tabelę świadków protokołu. Rozpoznanie, że rozszerzenie pakietów wymaga statycznej widoczności całego pakietu w miejscu wywołania, jest kluczowe dla utrzymania wydajności.
To ograniczenie myli kandydatów, którzy oczekują struct Storage<each T> { repeat var item: each T } jako deklaracji odrębnych właściwości przechowywanych dla każdego elementu pakietu. Swift zabrania tego, ponieważ właściwości przechowywane wymagają stałych przesunięć i kroków znanych tabeli świadków dla zarządzania pamięcią. Liczba właściwości zmieniająca się wariacyjnie stworzyłaby struktury o zmiennej wielkości, naruszając wymagania stabilności ABI dla typów ogólnych — tabela świadków wartości oczekuje, że układ statyczny będzie kopiowany, przenoszony i destruktowany. Wymagając agregacji w (repeat each T), kompilator traktuje pakiet jako jedną wartość kompozytową z układem pochodzącym z iloczynu kartezjańskiego jego elementów. To zapewnia, że każda specjalizacja Storage ma deterministyczny układ binarny, pozwalając czasowi wykonania na wybór odpowiednich funkcji świadków wartości bez dynamicznych wyszukiwań metadanych. Zrozumienie tego rozróżnienia między nietrwałymi pakietami parametrów (argumenty funkcji) a trwałym przechowywaniem (pola struktur) wyjaśnia, dlaczego pakiety muszą być "zamrożone" w krotkach dla trwałego przechowywania.