До Swift 5.9 разработчики сталкивались с серьезным ограничением выразительности при написании обобщенного кода, который работал с разнотипными коллекциями типов. Функции, требующие переменное количество аргументов с различными, сохраненными типами, были вынуждены прибегать к стиранию типов через Any или экзистенциальные контейнеры (any P), жертвуя безопасностью во время компиляции и неся накладные расходы на аллокацию в куче. Введение Параметрических пакетов (SE-0393, SE-0398 и SE-0399) принесло вариативные дженерики в Swift, позволяя языку выражать шаблоны, для которых раньше требовалось бы метапрограммирование шаблонов C++ или вариативные трейты Rust. Это развитие закрыло фундаментальные пробелы в обобщенном программировании, позволяя создавать типобезопасные, нулевые абстракции над разнотипными данными без ручной генерации перегрузок.
Основной задачей было реализовать механизм, который мог бы принимать произвольное количество обобщенных аргументов — каждый потенциально различного типа — при этом сохраняя статическую информацию о типах через цепочку вызовов. Решения до появления параметрических пакетов, использующие [Any], требовали приведения типов во время выполнения и не сохраняли отношения типов, что мешало оптимизациям компилятора, таким как инлайнинг и специализированная диспетчеризация. Альтернативно, ручная генерация перегрузок для арности от 1 до N (например, <T1>, <T1, T2>, <T1, T2, T3>) создавала избыточность бинарного кода и накладывала произвольные ограничения на количество аргументов. Решение должно было поддерживать итерацию по пакету во время компиляции, когда компилятор генерирует мономорфизированный код, специфичный для каждого типа сигнатуры вызова, без введения расширений времени выполнения или индикации таблицы свидетелей для простых типов значений.
Swift реализует параметрические пакеты через расширение пакетов, рассматривая паттерн repeat each T как шаблон во время компиляции для генерации кода. Когда функция объявляет параметр пакета типов <each T> и принимает пакет значений repeat each T, компилятор выполняет моноломорфизацию на месте вызова, расширяя обобщенное тело в конкретный код для каждого элемента в пакете. Это отличается от однородных вариативных типов (например, Int...), поскольку каждый элемент сохраняет свою уникальную идентичность типа. Ключевое слово repeat сигнализирует фазе генерации SIL (Swift Intermediate Language) о том, что последующее выражение должно быть дублировано для каждого элемента пакета, при этом типы подставляются соответственно. Эта трансформация устраняет проблему с упаковкой, поскольку типы значений остаются на стеке в своем конкретном представлении, а вызовы функций диспетчеризуются статически без накладных расходов экзистенциального контейнера.
// Функция, принимающая разнородный пакет параметров func describeValues<each T>(_ values: repeat each T) { // Компилятор расширяет этот цикл во время компиляции repeat print("Тип: \(type(of: each values)), Значение: \(each values)") } // Использование генерирует специализированный код, эквивалентный: // describeValues(Int, String, Double) describeValues(42, "Swift", 3.14)
Наша команда разрабатывала высокопроизводительный фреймворк для обработки данных для iOS, где пользователям было необходимо связывать разнородные шаги трансформации (например, DecodeJSON<T>, Validate<U>, Map<V>) в единую исполнительную граф. API требовал функции pipeline, принимающей любое количество этих шагов, каждый с различными типами входных и выходных данных, при этом сохраняя знания о потоке данных во время компиляции, чтобы обеспечить оптимизацию.
Сначала мы реализовали перегрузки для 1 до 6 обобщенных аргументов (например, func pipeline<T1, T2>(_: T1, _: T2)). Это сохранило статические типы и позволило LLVM инлайнить всю цепочку. Тем не менее, этот подход был многословным и непрактичным, требуя сотни строк почти идентичного кода. Это искусственно ограничивало пользователей шестью шагами, и каждая дополнительная арность экспоненциально увеличивала размер бинарного кода из-за дублирования кода. Когда требования изменились, чтобы поддерживать восемь шагов, усилия по рефакторингу были значительными.
Затем мы попытались определить протокол AnyPipelineStep с связанными типами, а затем использовать [any AnyPipelineStep] в качестве параметра. Это поддерживало неограниченное количество шагов, но вынуждало каждый тип значения (структуры, содержащие декодированные данные) помещать в экзистенциальные контейнеры с аллокацией в куче. Профилирование производительности показало, что 30% времени ЦП тратится на операции swift_retain и swift_release с этими контейнерами. Кроме того, компилятор больше не мог оптимизировать на границах шагов, потому что связанные типы были стёрты, требуя динамической переустановки на каждом сгибе.
С Swift 5.9 мы рефакторили API, чтобы использовать func pipeline<each Step: PipelineStep>(steps: repeat each Step). Это позволило компилятору генерировать уникальную специализацию для каждой уникальной композиции конвейера, встреченной в кодовой базе. Каждый шаг сохранял свой конкретный тип, позволяя агрессивному инлайнингу и аллокации на стеке для временных структур данных. Ключевое слово repeat позволяло нам итеративно проверять совместимость типов между смежными шагами во время компиляции.
Мы выбрали параметрические пакеты, потому что они устранили ограничение арности без ущерба для производительности. В отличие от экзистенциальных типов, пакеты сохраняли обобщенную сигнатуру для оптимизатора Swift, что приводило к нулевым затратам на абстракцию. Рефакторинг уменьшил размер бинарного фреймворка на 35% по сравнению с подходом перегрузок и улучшил пропускную способность в 4 раза по сравнению с экзистенциальным подходом. Разработчики теперь могли составлять конвейеры произвольной длины с полной поддержкой автозаполнения для каждого типа входных/выходных данных, выявляя несоответствия данных на этапе сборки, а не во время интеграционного тестирования.
Кандидаты часто предполагают, что ограничения пакетов ведут себя как одно единственное ограничение на обобщенный тип, но Swift требует явных паттернов repeat в предложениях where. При ограничении каждого элемента пакета T соответствовать Container с различными ассоциированными типами Item синтаксис становится следующим: func process<each T: Container>(_ items: repeat each T) where repeat each T.Item: Equatable. Компилятор выполняет структурное решение ограничений, расширяя элемент where по элементам в пакете. Общей ошибкой является попытка использовать одно общее ограничение на ассоциированные типы для всего пакета, что не удается, поскольку каждый T.Item является отдельным типом. Понимание того, что ограничения пакетов создают конъюнкцию требований для каждого элемента, а не единое объединенное ограничение, важно для отладки ошибок вывода.
Разработчики часто верят, что параметрические пакеты гарантируют абстракцию без затрат во всех контекстах, но пересечение границ ABI или использование непрозрачных типов результата может вынудить использовать упаковку. В частности, когда параметрический пакет захвачен в замыкающем контексте, переданном функции в другой области устойчивости (например, в интерфейсе общедоступной библиотеки), Swift может создать универсальную инстанцию во время выполнения, используя таблицы свидетелей вместо статической специализации. Точно так же возвращение some Collection из итерации пакета заставляет компилятор использовать экзистенциальный контейнер, поскольку конкретный возвращаемый тип варьируется в зависимости от каждого элемента пакета. Это влияет на макет памяти, вводя аллокацию в куче для встроенного буфера экзистенциального (три слова) и добавляя индирекцию через таблицу свидетелей протоколов. Признание того, что расширение пакетов требует статической видимости всего пакета в месте вызова, имеет решающее значение для поддержания производительности.
Это ограничение сбивает с толку кандидатов, которые ожидают, что struct Storage<each T> { repeat var item: each T } объявит отдельные хранимые свойства для каждого элемента пакета. Swift запрещает это потому, что хранимые свойства требуют фиксированных смещений и шагов, известных таблице свидетелей значений для управления памятью. Переменное количество свойств создало бы структуры переменного размера, нарушая требования стабильности ABI для обобщенных типов — таблица свидетелей значений ожидает статического макета для копирования, перемещения и уничтожения экземпляров. Требуя агрегации в (repeat each T), компилятор рассматривает пакет как одно составное значение с макетом, основанным на декартовом произведении его элементов. Это гарантирует, что каждая специализация Storage имеет детерминированный бинарный макет, позволяя времени выполнения выбрать соответствующие функции свидетелей значений без динамических проверок метаданных. Понимание этого различия между временными параметрическими пакетами (аргументы функции) и постоянным хранилищем (поля структур) разъясняет, почему пакеты должны быть "заморожены" в кортеже для постоянного хранения.