Prima di Swift 5.9, gli sviluppatori si trovavano ad affrontare una significativa limitazione espressiva quando scrivevano codice generico che operava su collezioni eterogenee di tipi. Le funzioni che richiedevano vari numeri di argomenti con tipi distinti e preservati erano costrette a ricorrere alla cancellazione del tipo tramite Any o contenitori esistenziali (any P), sacrificando la sicurezza a tempo di compilazione e incorrendo in costi di allocazione nell'heap. L'introduzione dei Pacchetti di Parametri (SE-0393, SE-0398 e SE-0399) ha portato i generici variadici in Swift, consentendo al linguaggio di esprimere schemi precedentemente richiesti dalla metaprogrammazione dei template di C++ o dai tratti variadici di Rust. Questa evoluzione ha colmato lacune fondamentali nella programmazione generica, consentendo astrazioni sicure per il tipo e a costo zero su dati eterogenei senza la necessità di generazione manuale di overload.
La sfida principale consisteva nell'implementare un meccanismo che potesse accettare un numero arbitrario di argomenti generici—ognuno potenzialmente di un tipo distinto—pur mantenendo le informazioni statiche sul tipo attraverso la catena di chiamata. Le soluzioni precedenti all'uso dei pacchetti di parametri che utilizzavano [Any] richiedevano il casting a tempo di esecuzione e non riuscivano a preservare le relazioni di tipo, impedendo ottimizzazioni da parte del compilatore come l'inlining e la dispatch specializzata. In alternativa, generare manualmente overload per arità da 1 a N (es. <T1>, <T1, T2>, <T1, T2, T3>) creava bloat binario e imponeva limiti arbitrari sul conteggio degli argomenti. La soluzione doveva supportare l'iterazione del pacchetto a tempo di compilazione, dove il compilatore genera codice monomorfizzato specifico per la firma del tipo di ciascun sito di chiamata, senza introdurre boxing a tempo di esecuzione o indirection della tabella dei testimoni per tipi di valore semplici.
Swift implementa i pacchetti di parametri attraverso l'espansione del pacchetto, trattando il modello repeat each T come un modello a tempo di compilazione per la generazione di codice. Quando una funzione dichiara un pacchetto di parametri di tipo <each T> e accetta un pacchetto di valori repeat each T, il compilatore esegue la monomorfizzazione nel sito di chiamata, espandendo il corpo generico in codice concreto per ciascun elemento del pacchetto. Questo è distinto dai variadici omogenei (es. Int...) perché ogni elemento mantiene la propria identità di tipo unica. La parola chiave repeat segnala alla fase di generazione SIL (Swift Intermediate Language) che l'espressione successiva deve essere duplicata per ciascun elemento del pacchetto, con i tipi sostituiti di conseguenza. Questa trasformazione elimina il boxing poiché i tipi di valore rimangono nello stack nel loro layout concreto, e le chiamate di funzione vengono dispatchate staticamente senza l'overhead del contenitore esistenziale.
// Funzione che accetta un pacchetto di parametri eterogenei func describeValues<each T>(_ values: repeat each T) { // Il compilatore espande questo ciclo a tempo di compilazione repeat print("Tipo: \(type(of: each values)), Valore: \(each values)") } // L'uso genera codice specializzato equivalente a: // describeValues(Int, String, Double) describeValues(42, "Swift", 3.14)
Il nostro team stava architettando un framework per pipeline di dati ad alte prestazioni per iOS, in cui gli utenti dovevano concatenare passaggi di trasformazione eterogenei (es. DecodeJSON<T>, Validate<U>, Map<V>) in un singolo grafo di esecuzione. L'API richiedeva una funzione pipeline che accettasse un numero qualsiasi di questi passaggi, ciascuno con tipi di input e output distinti, mantenendo la conoscenza a tempo di compilazione del flusso di dati per abilitare i passaggi di ottimizzazione.
Inizialmente abbiamo implementato overload per 1 fino a 6 argomenti generici (es. func pipeline<T1, T2>(_: T1, _: T2)). Questo ha preservato i tipi statici e consentito a LLVM di inlinare l'intera catena. Tuttavia, questo approccio era verboso e difficile da mantenere, richiedendo centinaia di righe di codice quasi identico. Limitava artificialmente gli utenti a sei passaggi, e ogni arità aggiuntiva aumentava esponenzialmente la dimensione binaria a causa della duplicazione del codice. Quando i requisiti sono cambiati per supportare otto passaggi, lo sforzo di rifattorizzazione è stato notevole.
Successivamente, abbiamo provato a definire un protocollo AnyPipelineStep con tipi associati, poi utilizzando [any AnyPipelineStep] come parametro. Questo supportava passaggi illimitati ma costringeva ogni tipo di valore (strutture che trasportano dati decodificati) in contenitori esistenziali allocati nell'heap. La profilazione delle prestazioni ha rivelato che il 30% del tempo CPU veniva speso in operazioni di swift_retain e swift_release su queste scatole. Inoltre, il compilatore non poteva più ottimizzare attraverso i confini dei passaggi poiché i tipi associati erano stati cancellati, richiedendo il casting dinamico a ciascun incrocio.
Con Swift 5.9, abbiamo rifattorizzato l'API per utilizzare func pipeline<each Step: PipelineStep>(steps: repeat each Step). Questo ha consentito al compilatore di generare una specializzazione unica per ogni composizione di pipeline distintiva incontrata nel codice sorgente. Ogni passaggio ha mantenuto il proprio tipo concreto, abilitando un inlining aggressivo e l'allocazione nello stack per strutture dati transitorie. La parola chiave repeat ci ha permesso di iterare sul pacchetto per verificare la compatibilità dei tipi tra passaggi adiacenti a tempo di compilazione.
Abbiamo adottato i pacchetti di parametri perché hanno eliminato la limitazione di arità senza sacrificare le prestazioni. A differenza degli esistenziali, i pacchetti hanno preservato la firma generica per l'ottimizzatore di Swift, risultando in astrazioni a costo zero. La rifattorizzazione ha ridotto la dimensione binaria del framework del 35% rispetto all'approccio overload e ha migliorato il throughput di 4 volte rispetto all'approccio esistenziale. Gli sviluppatori potevano ora comporre pipeline di lunghezza arbitraria con pieno supporto per il completamento automatico dei tipi di input/output specifici di ciascun passaggio, catturando le incompatibilità nei dati al momento della compilazione piuttosto che durante i test di integrazione.
I candidati presumono frequentemente che i vincoli dei pacchetti si comportino come vincoli generici singoli, ma Swift richiede espliciti modelli repeat nelle clausole where. Quando si vincola ciascun elemento del pacchetto T a conformarsi a Container con tipi associati Item diversi, la sintassi diventa func process<each T: Container>(_ items: repeat each T) where repeat each T.Item: Equatable. Il compilatore esegue la risoluzione dei vincoli strutturale, espandendo la clausola where elemento per elemento attraverso il pacchetto. Un comune modo di fallire è cercare di usare un vincolo di tipo associato singolo per l'intero pacchetto, il che fallisce perché ciascun T.Item è un tipo distinto. Comprendere che i vincoli dei pacchetti generano una congiunzione di requisiti per elemento, piuttosto che un vincolo unico e unificato, è essenziale per il debug degli errori di inferenza.
Gli sviluppatori credono spesso che i pacchetti di parametri garantiscano astrazioni a costo zero in tutti i contesti, ma attraversare i confini ABI o utilizzare tipi di risultato opachi può forzare il boxing. Specificamente, quando un pacchetto di parametri viene catturato in una chiusura in fuga passata a una funzione in un dominio di resilienza diverso (es. un'interfaccia di libreria pubblica), Swift può emettere un'istanza generica a tempo di esecuzione utilizzando le tabelle dei testimoni piuttosto che la specializzazione statica. Allo stesso modo, restituire some Collection da un'iterazione del pacchetto costringe il compilatore a utilizzare un contenitore esistenziale perché il tipo di ritorno concreto varia con ciascun elemento del pacchetto. Questo influisce sul layout della memoria introducendo l'allocazione nell'heap per il buffer inline dell'esistenziale (tre parole) e aggiungendo indirection attraverso la tabella dei testimoni di protocollo. Riconoscere che l'espansione del pacchetto richiede visibilità statica dell'intero pacchetto nel sito di chiamata è cruciale per mantenere le prestazioni.
Questa limitazione confonde i candidati che si aspettano che struct Storage<each T> { repeat var item: each T } dichiari proprietà memorizzate distinte per ciascun elemento del pacchetto. Swift vieta questo perché le proprietà memorizzate richiedono offset e passi fissi noti alla tabella dei testimoni di valore per la gestione della memoria. Un numero variadic di proprietà creerebbe strutture di dimensioni variabili, violando i requisiti di stabilità ABI per i tipi generici—la tabella dei testimoni di valore si aspetta un layout statico per copiare, spostare e distruggere le istanze. Richiedendo aggregazione in (repeat each T), il compilatore tratta il pacchetto come un singolo valore composito con un layout derivato dal prodotto cartesiano dei suoi elementi. Questo garantisce che ogni specializzazione di Storage abbia un layout binario deterministico, consentendo al runtime di selezionare le appropriate funzioni dei testimoni di valore senza ricerche dinamiche di metadati. Comprendere questa distinzione tra pacchetti di parametri transitori (argomenti di funzione) e archiviazione persistente (campi strutturali) chiarisce perché i pacchetti devono essere "gelati" in tuple per l'archiviazione persistente.