L'histoire remonte aux langages de programmation fonctionnels comme Haskell (appel par nécessité) et Scala (appel par nom), où l'évaluation paresseuse empêche les calculs inutiles. Swift a adopté ce modèle pour permettre une syntaxe claire pour les assertions et les opérateurs de contrôle de flux (&&, ||) sans sacrifier les performances. Le problème survient lorsque les arguments sont coûteux à calculer ou ont des effets secondaires, mais l'évaluation anticipée force l'exécution indépendamment de la nécessité.
Le compilateur transforme le site d'appel en encapsulant implicitement l'expression d'argument à l'intérieur d'une closure à zéro argument { expression }. Cette closure (thunk) est ensuite passée à la fonction au lieu du résultat déjà évalué. Lorsque le corps de la fonction accède au paramètre, il invoque la closure, déclenchant l'évaluation à ce moment-là. En ce qui concerne l'ARC, la closure synthétisée capture des variables de la portée extérieure par référence ; si l'autoclosure est marquée @escaping, elle alloue le contexte de la closure sur le tas, retenant les types de référence capturés et prolongeant potentiellement leur durée de vie au-delà de la portée d'origine.
Considérons le développement d'un tableau de bord d'analyse de trading à haute fréquence où les chaînes de journalisation de débogage nécessitent une lourde sérialisation JSON d'objets de données de marché. Le problème était que les builds de production désactivaient les journaux de débogage, mais l'interpolation de chaîne log("Data: \(heavyObject.serialize())") était exécutée à chaque tick de marché, consommant 30 % de CPU inutilement.
Une solution consistait à passer une closure de fin explicite : log { "Data: \(heavyObject.serialize())" }. Cela différée parfaitement l'évaluation, mais la syntaxe encombrait le code avec des centaines d'accollades, réduisant la lisibilité et rendant les recherches grep difficiles. Les développeurs oubliaient aussi parfois la syntaxe de la closure, revenant accidentellement à l'évaluation anticipée.
Une autre approche utilisait des définitions de macros de préprocesseur ou des configurations de build pour supprimer complètement le code de journalisation. Bien que cela ait éliminé le surcoût d'exécution, cela a empêché le débogage en situations d'urgence de production et nécessitait des builds binaires séparés, compliquant le pipeline CI/CD.
La solution choisie a mis en œuvre @autoclosure combinée avec @escaping pour le paramètre message : func log(_ message: @autoclosure @escaping () -> String). Cela a préservé la syntaxe d'appel naturelle—exactement comme la version anticipée d'origine—tout en garantissant une exécution différée. Le @escaping a permis un dispatch asynchrone vers une file d'attente de journalisation en arrière-plan, bien que cela ait nécessité une gestion soigneuse de la liste de capture pour éviter de retenir des contrôleurs de vue plus longtemps que nécessaire lors des mises à jour de graphique.
Le résultat a réduit l'utilisation de CPU en production de 28 %, gérant avec succès 50 000 ticks par seconde. Cependant, l'équipe a découvert un cycle de rétention lorsque la closure du message capturait self implicitement à travers self.marketData, gardant les contrôleurs de vue actifs pendant les transitions de navigation. Des listes de capture explicites [weak self] ont résolu ce problème, mais ont nécessité des règles de linting pour éviter les régressions.
Pourquoi @autoclosure capture-t-il des variables par référence plutôt que par valeur par défaut, et comment cela peut-il conduire à des mutations inattendues si la closure est exécutée de manière asynchrone ?
Par défaut, les closures dans Swift capturent des variables par référence pour maintenir la cohérence avec la sémantique standard des closures. Lorsqu'un paramètre @autoclosure @escaping capture une var de la portée extérieure et que la fonction exécute la closure plus tard (par exemple, sur une file d'attente en arrière-plan), les mutations de cette variable entre le site d'appel et le moment d'exécution deviennent visibles à l'intérieur de la closure. Cela diffère de l'évaluation anticipée où la valeur est fixée au site d'appel. Pour forcer la capture de valeur, il faut explicitement masquer la variable dans une liste de capture comme [val = variable], bien que cette syntaxe soit rarement utilisée avec autoclosure en raison de sa nature implicite.
Comment le compilateur optimise-t-il les paramètres @autoclosure non échappants au niveau SIL par rapport aux variantes échappantes, et quelles limites existent sur ces optimisations ?
Le compilateur Swift traite l'autoclosure non échappante comme un pointeur de fonction direct avec un contexte alloué sur la pile, ce qui peut potentiellement intégrer entièrement le corps de la closure grâce à la spécialisation de fonction si le callee l'invoque immédiatement. Cela élimine l'allocation sur le tas et le surcoût de comptage de références. Cependant, une fois marqué @escaping, la closure doit allouer son contexte sur le tas pour survivre à la portée de la fonction, entraînant un trafic de conservation/libération ARC. Les candidats oublient souvent que même une autoclosure non échappante peut empêcher certaines optimisations si la closure est passée à une autre fonction non échappante, créant des chaînes de thunk imbriquées qui bloquent l'intégration.
Quelle interaction spécifique se produit entre @autoclosure et le mot-clé rethrows lorsque le corps de l'autoclosure contient une expression qui lance une exception, et pourquoi cela importe-t-il pour la conception d'API ?
Lorsque qu'une fonction est marquée rethrows et accepte une @autoclosure lançant une exception, le compilateur vérifie que la seule exception provient de l'invocation de l'autoclosure. Cela permet à la fonction de propager les erreurs sans être marquée throws elle-même, maintenant une interface claire pour les sites d'appel ne lançant pas d'exception. Cela est important car cela permet des opérateurs de court-circuit tels que try lhs || expensiveFailableRhs() où le côté droit n'est évalué et ne lance d'exception que si le gauche est faux. Les candidats manquent souvent de remarquer que rethrows avec autoclosure nécessite que la closure soit le seul composant lançant ; si le corps de la fonction effectue d'autres opérations lançant directement, le compilateur rejette l'annotation rethrows.