Swift a introduit les constructeurs de résultat (initialement appelés constructeurs de fonction) dans la version 5.1 pour permettre une syntaxe déclarative pour des bibliothèques comme SwiftUI. Avant cela, la création de structures de données hiérarchiques nécessitait des appels d'initialiseur profondément imbriqués qui étaient visuellement encombrants et difficiles à maintenir. La fonctionnalité a été inspirée par des bibliothèques de combineurs de parseurs et des monades de programmation fonctionnelle, adaptées pour s'intégrer au système de types statiques de Swift tout en préservant la familiarité avec la syntaxe impérative.
Les développeurs avaient besoin d'un moyen d'écrire des déclarations séquentielles qui construisent des valeurs complexes sans sacrifier la sécurité de type à la compilation de Swift ou introduire des surcharges d'exécution. Le défi central consistait à prendre en charge des structures de contrôle de flux comme les instructions if et les boucles for dans ces constructions, où des branches différentes pourraient produire des types différents qui doivent être unifiés en un seul type de résultat. Utiliser simplement des tableaux de types existentiels entraînerait une perte d'informations de type concrètes et forcerait une dispatch dynamique, sapant les chemins de code critiques pour les performances.
Le compilateur Swift effectue une transformation source-à-source pendant la phase d'analyse sémantique, réécrivant le corps de la fermeture du constructeur de résultat en une série d'appels de méthode statiques sur le type du constructeur. Les déclarations séquentielles deviennent des arguments pour buildBlock, les conditionnels sont désucrés en appels à buildEither(first:) et buildEither(second:), et les branches optionnelles utilisent buildOptional. Cette transformation se produit avant la vérification de type, permettant au compilateur de vérifier que les types composés correspondent au type de retour attendu tout en générant du code en ligne efficace équivalent aux appels imbriqués manuels.
@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" } }
Une équipe backend avait besoin de construire des pipelines de requêtes de base de données en utilisant une interface fluente. Ils voulaient une syntaxe où les développeurs pouvaient lister les opérations verticalement plutôt que de chaîner des méthodes avec des points, tout en maintenant une vérification à la compilation de la compatibilité du schéma.
Ils ont d'abord envisagé d'utiliser la chaînage de méthodes traditionnelle où chaque opération retournait un objet Query modifié. Cette approche fonctionnait pour des pipelines linéaires simples mais devenait ingérable lorsqu'il s'agissait d'ajouter conditionnellement des filtres ou des jointures, nécessitant des variables temporaires et des expressions ternaires complexes pour maintenir la chaîne. Elle forçait également tous les types intermédiaires à être les mêmes, empêchant les optimisations spécifiques à chaque étape.
Une autre option était d'accepter un tableau de modificateurs basés sur des fermetures [(Query) -> Query]. Cela permettait la syntaxe verticale souhaitée, mais supprimait complètement les informations de type à chaque étape, empêchant la validation à la compilation de l'existence des colonnes ou des incohérences de type. Les benchmarks ont montré que cela introduisait une surcharge d'exécution de 15 % en raison de l'incapacité d'inliner les fermetures de transformation.
L'équipe a mis en œuvre un constructeur de résultat personnalisé @QueryBuilder. Ils ont défini des méthodes buildBlock surchargées pour accepter des étapes de pipeline hétérogènes et les combiner en un tuple typé, buildEither pour gérer les clauses WHERE conditionnelles sans effacer les types, et buildArray pour les opérations JOIN générées par des boucles for. Cela a préservé la syntaxe déclarative verticale tout en maintenant des abstractions sans coût, permettant à l'optimiseur LLVM d'inliner la construction de tout le pipeline. Le code de définition de requête est devenu 50 % plus court, et les incohérences de schéma étaient détectées à la compilation plutôt que lors des tests d'intégration.
Comment le compilateur désuétise-t-il une instruction switch au sein d'un constructeur de résultat lorsque différents cas retournent différents types concrets ?
Le compilateur transforme un switch en un arbre binaire d'appels imbriqués de buildEither, nécessitant que le vérificateur de type unifie toutes les branches en un seul type. Si des cas retournent des types différents (par exemple, Text contre Image dans SwiftUI), la compilation échoue à moins que le constructeur ne fournisse un effacement de type. Les candidats supposent souvent que switch reçoit un traitement spécial de dispatch à plusieurs voies, mais cela cascade en décisions binaires (premier cas contre le reste). La solution nécessite soit de s'assurer que tous les cas retournent le même type concret, soit d'implémenter buildExpression pour envelopper les valeurs dans un conteneur existentiel comme AnyView, bien que cela sacrifice les opportunités d'optimisation statique.
Pourquoi l'ajout d'un contrôle @available à l'intérieur d'un constructeur de résultat nécessite-t-il un traitement spécial via buildLimitedAvailability ?
Lorsqu'un constructeur de résultat contient du code enveloppé dans des vérifications de disponibilité (par exemple, if #available(iOS 15, *)), le compilateur ne peut pas garantir que les composants dans le bloc protégé existent sur tous les cibles de déploiement. Sans buildLimitedAvailability, le vérificateur de type échoue car il tente de vérifier le code protégé par la disponibilité par rapport à la cible de déploiement minimale. Cette méthode agit comme un filtre à la compilation, permettant au constructeur de substituer un espace réservé ou une valeur vide lors de la cible de versions OS plus anciennes. Les candidats manquent que cela empêche des erreurs de lien "symbole non trouvé" en garantissant que les chemins de code non disponibles sont entièrement effacés de type ou remplacés avant la génération binaire.
Quelle est la différence précise entre buildExpression et buildBlock, et quand est-il nécessaire d'implémenter buildExpression pour la sécurité des types ?
buildBlock combine plusieurs composants déjà transformés en un résultat final, tandis que buildExpression est un crochet optionnel qui transforme des expressions individuelles avant qu'elles ne soient passées à buildBlock. Les candidats manquent souvent que buildExpression permet un effacement de type précoce au niveau de l'expression, permettant aux types hétérogènes d'être unifiés avant la combinaison. Par exemple, le ViewBuilder de SwiftUI utilise buildExpression pour envelopper implicitement les vues dans AnyView uniquement lorsque cela est nécessaire, ou pour appliquer des modificateurs de vue. Sans comprendre cette distinction, les développeurs ne peuvent pas implémenter de constructeurs qui gèrent avec grâce des incohérences de type entre des déclarations séquentielles sans forcer l'utilisateur à caster manuellement chaque expression.