Result Builder — ce que c'est, syntaxe et application

Qu'est-ce que Result Builder ?

Result Builder (anciennement connu sous le nom de function builders) est un mécanisme Swift qui permet de transformer une séquence d'expressions séparées par des sauts de ligne en une seule valeur. Il est déclaré à l'aide de l'attribut @resultBuilder appliqué à une structure qui implémente des méthodes de transformation statiques.

Avant les result builders, la syntaxe déclarative du body de SwiftUI était impossible. Au lieu d'une liste compacte de vues, les développeurs devaient écrire manuellement des appels TupleView. Result Builder encapsule automatiquement chaque expression, prend en charge les branchements et les boucles, cachant la complexité de la composition au développeur.

Selon Swift Evolution SE-0289, acceptée en 2022, le result builder est une évolution de l'idée des function builders (SE-0258, Swift 5.1). Changements principaux : renommage de @_functionBuilder en @resultBuilder et extension aux paramètres de fonction, permettant d'utiliser les builders pour n'importe quel argument de closure, pas seulement pour les corps de vue.

Utilisez les result builders lorsque vous devez fournir aux utilisateurs de votre bibliothèque une syntaxe déclarative pour construire des structures complexes — configurations, requêtes, composants d'interface utilisateur — sans écrire de code assembleur impératif.

Comment fonctionne Result Builder

Le compilateur Swift transforme chaque bloc de code marqué avec @resultBuilder en une séquence d'appels aux méthodes statiques du builder. Regardons un builder simple qui concatène des chaînes :

@resultBuilder
struct StringBuilder {
    static func buildBlock(_ parts: String...) -> String {
        parts.joined(separator: " ")
    }
}

En utilisant ce builder — chaque chaîne sur une ligne séparée est concaténée avec un espace :

@StringBuilder
func greeting() -> String {
    "Hello"
    "World"
    "from"
    "Swift"
}
// Le compilateur transforme cela en:
// StringBuilder.buildBlock("Hello", "World", "from", "Swift")
// Résultat : "Hello World from Swift"

Le compilateur regroupe les expressions consécutives et les passe comme paramètres variadiques à buildBlock. Si un if apparaît entre les expressions, le compilateur appelle buildOptional ou buildEither pour le branchement. Pour les boucles for-in, il appelle buildArray. Ainsi, le code Swift ordinaire est transformé en une chaîne d'appels qui construisent la valeur finale.

Méthodes du builder : buildBlock, buildOptional, buildEither

Chaque result builder définit un ensemble de méthodes statiques que le compilateur appelle pendant la transformation. Les méthodes principales :

Une implémentation minimale nécessite seulement buildBlock avec des paramètres variadiques — cela suffit pour les blocs sans branchement. Ajouter buildOptional et buildEither inclut la prise en charge des constructions conditionnelles, et buildArray pour les boucles. Selon la Documentation Swift (2025), il est recommandé d'implémenter toutes les méthodes pour une flexibilité maximale du DSL.

buildExpression permet d'accepter des expressions de différents types et de les convertir en un seul type de builder. Par exemple, dans @ViewBuilder, buildExpression accepte Text, Image, Button et les convertit en type commun View.

Création d'un Result Builder personnalisé

Examinons la création d'un builder pour construire des chaînes HTML. Ce DSL permettra d'écrire du HTML déclaratif directement en Swift :

@resultBuilder
enum HTMLBuilder {
    static func buildBlock(_ components: String...) -> String {
        components.joined()
    }

    static func buildOptional(_ component: String?) -> String {
        component ?? ""
    }

    static func buildEither(first component: String) -> String {
        component
    }

    static func buildEither(second component: String) -> String {
        component
    }

    static func buildArray(_ components: [String]) -> String {
        components.joined()
    }
}

Utilisation du builder personnalisé pour générer du HTML :

func div(@HTMLBuilder _ content: () -> String) -> String {
    "<div>\(content())</div>"
}

func p(_ text: String) -> String {
    "<p>\(text)</p>"
}

let page = div {
    p("Hello")
    p("World")

    if showFooter {
        p("Pied de page")
    }
}
// Résultat : <div><p>Hello</p><p>World</p><p>Footer</p></div>

Selon l'article “Building Custom Result Builders in Swift” de Swift.org (2025), les builders personnalisés sont utilisés dans les bibliothèques pour construire des fichiers de configuration, des composants d'interface utilisateur, du mappage de données et même des requêtes de base de données — partout où une syntaxe déclarative avec prise en charge des branchements est nécessaire.

@ViewBuilder dans SwiftUI

@ViewBuilder est un result builder intégré à SwiftUI qui est appliqué au paramètre content de la plupart des vues conteneurs : VStack, HStack, ZStack, Group, List et la propriété body elle-même. Il permet d'écrire plusieurs vues sur des lignes séparées sans virgules ni encapsulations.

@ViewBuilder implémente toutes les méthodes du result builder, y compris la prise en charge de if-else, switch et for-in. Quand une condition est vraie, buildEither(first:) retourne une vue ; quand elle est fausse, buildEither(second:) en retourne une autre. Les deux branches doivent retourner le même type, mais SwiftUI utilise AnyView en interne ou l'effacement de type via ConditionalContent.

struct GreetingView: View {
    let isLoggedIn: Bool

    var body: some View {
        VStack {
            Image(systemName: "person.circle")
            Text("Profil")
                .font(.title)

            if isLoggedIn {
                Text("Bon retour !")
                    .foregroundColor(.green)
            } else {
                Button("Connexion") { }
            }
        }
    }
}

Sans @ViewBuilder, le même code nécessiterait Group pour chaque section conditionnelle ou l'utilisation de AnyView, ce qui nuit aux performances. @ViewBuilder sélectionne automatiquement la représentation la plus efficace — ConditionalContent ou TupleView — pour chaque combinaison.

Limitations de Result Builder

La première limitation est le nombre maximum d'expressions dans buildBlock. La bibliothèque standard Swift définit des surcharges de buildBlock pour 2 à 10 expressions. Si un bloc contient plus de 10 expressions, le compilateur générera une erreur. La solution est le regroupement via Group ou VStack pour diviser en sous-blocs.

La deuxième limitation est l'absence de prise en charge des variables et des affectations à l'intérieur du bloc du builder. Vous ne pouvez pas déclarer let x = 5 dans @ViewBuilder. Toutes les expressions doivent être des expressions retournant une valeur du type du builder. Pour les calculs intermédiaires, utilisez des calculs en dehors du builder ou buildExpression avec prise en charge de différents types.

La troisième limitation est la complexité de débogage. Les erreurs de compilation dans un result builder produisent souvent des messages confus, en particulier lorsque les types ne correspondent pas dans les branches if/else. Utilisez des types de retour explicites et AnyView pour le débogage, bien que ce dernier réduise les performances. Selon Hacking with Swift (2025), un conseil pratique est de commencer par un builder simple sans branchement et d'ajouter progressivement la prise en charge des constructions conditionnelles.