Swift ввел строительные результаты (изначально называвшиеся строительством функций) в версии 5.1, чтобы обеспечить декларативный синтаксис для таких библиотек, как SwiftUI. Ранее создание иерархических структур данных требовало глубоко вложенных вызовов инициализаторов, которые были визуально сложными и трудными для поддержки. Эта функция была вдохновлена библиотеками комбинирования парсеров и монад функционального программирования, адаптированными для статической типизации Swift, сохраняя при этом привычный императивный синтаксис.
Разработчикам нужен был способ писать последовательные инструкции, которые конструируют сложные значения, не жертвуя компиляционной типовой безопасностью Swift или не вводя накладные расходы на выполнение. Центральной задачей было поддержка конструкций управления потоком, таких как оператор if и циклы 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. Этот подход работал для простых линейных конвейеров, но становился непрактичным при условной добавлении фильтров или соединений, требуя временные переменные и сложные тернарные выражения для поддержки цепочки. Это также заставляло все промежуточные типы быть одинаковыми, что мешало этапным оптимизациям.
Другим вариантом было принятие массива модификаторов на основе замыканий [(Query) -> Query]. Это позволило желаемый вертикальный синтаксис, но полностью стерло информацию о типах на каждом шаге, препятствуя проверке существования столбца или несовпадения типов на этапе компиляции. Бенчмарки показали, что это привело к 15%-му накладному расходу времени выполнения из-за невозможности инлайнить замыкания трансформации.
Команда реализовала собственный строитель результата @QueryBuilder. Они определили перегруженные методы buildBlock, чтобы принять гетерогенные этапы конвейера и объединить их в типизированный кортеж, buildEither, чтобы обрабатывать условные WHERE-клаузулы без потери типов, и buildArray для генерируемых циклом for операций JOIN. Это сохранило вертикальный декларативный синтаксис при сохранении абстракций нулевых затрат, позволяя оптимизатору LLVM инлайнить всю конструкцию конвейера. Код определения запросов стал на 50% короче, а несоответствия схемы были обнаружены на этапе компиляции, а не во время интеграционного тестирования.
Как компилятор десугарирует оператор switch внутри строительного результата, когда разные случаи возвращают разные конкретные типы?
Компилятор преобразует switch в двоичное дерево вложенных вызовов buildEither, требуя от проверяющего типов объединить все ветви в один тип. Если случаи возвращают разные типы (например, Text против Image в SwiftUI), компиляция завершается неудачей, если строитель не предоставляет стирание типов. Кандидаты часто предполагают, что switch получает специальное многопутевое управление диспетчеризацией, но на самом деле он проходит через двоичные решения (первый случай против остальных). Решение требует либо обеспечить, чтобы все случаи возвращали один и тот же конкретный тип, либо реализовать buildExpression, чтобы обернуть значения в экзистенциальный контейнер, такой как AnyView, хотя это жертвует возможностями статической оптимизации.
Почему добавление проверки @available внутрь строительного результата требует специального обращения через buildLimitedAvailability?
Когда строитель результата содержит код, обернутый в проверки доступности (например, if #available(iOS 15, *)), компилятор не может гарантировать, что компоненты внутри защищенного блока существуют на всех целевых платформах. Без buildLimitedAvailability проверка типов завершается неудачей, поскольку она пытается проверить код, защищенный доступностью, в отношении минимального целевого хода. Этот метод выступает как фильтр времени компиляции, позволяя строителю подменять заполнитель или пустое значение при нацеливании на более старые версии OS. Кандидаты упускают из виду, что это предотвращает ошибки времени связывания "символ не найден", гарантируя, что недоступные пути кода полностью стерты или заменены до генерации бинарного файла.
Какова точная разница между buildExpression и buildBlock, и когда реализация buildExpression необходима для типовой безопасности?
buildBlock объединяет несколько уже преобразованных компонентов в конечный результат, в то время как buildExpression является необязательным хуком, который преобразует отдельные выражения до их передачи buildBlock. Кандидаты часто упускают из виду, что buildExpression позволяет проводить раннее стирание типов на уровне выражений, позволяя объединить гетерогенные типы перед комбинированием. Например, ViewBuilder в SwiftUI использует buildExpression, чтобы неявно обернуть представления в AnyView только при необходимости или применять модификаторы представлений. Без понимания этой разницы разработчики не могут реализовать строителей, которые элегантно обрабатывают несовпадения типов между последовательными инструкциями, не заставляя пользователя вручную приводить каждое выражение к нужному типу.