L'attribut @inlinable indique au compilateur Swift de sérialiser l'implémentation d'une fonction dans le fichier d'interface du module, permettant au corps d'être copié directement dans les modules clients au moment de la compilation pour permettre des optimisations agressives telles que la spécialisation générique et le repliement constant. Cependant, comme le code en ligne doit résoudre toutes les références de symbole au sein de l'unité de compilation du client, tout type, fonction ou propriété internal accessible par la fonction @inlinable doit être marqué avec @usableFromInline, ce qui les expose au compilateur sans les publier comme API publique.
// Dans un module de framework résilient @usableFromInline internal struct InternalBuffer { @usableFromInline var storage: [Int] } @inlinable public func fastSum(_ buffer: InternalBuffer) -> Int { // Peut accéder au stockage interne en raison de @usableFromInline return buffer.storage.reduce(0, +) }
Cette combinaison permet aux auteurs de bibliothèques d'offrir des abstractions sans coût où le code générique est monomorphisé dans le binaire client, bien que cela sacrifie une certaine flexibilité de l'ABI car le corps de la fonction devient partie de l'interface binaire stable.
Une équipe développant un framework d'apprentissage machine à haut débit avait besoin d'exposer une fonction de multiplication matricielle générique matmul<T: Numeric> aux applications clientes, mais le profilage a révélé que la surcharge des appels de fonction inter-modules et le manque de spécialisation réduisaient les performances de quarante pour cent par rapport à des boucles écrites à la main. La bibliothèque était distribuée sous forme de paquet Swift binaire, donc les optimisations au niveau source n'étaient pas disponibles pour les clients.
Une approche était de rendre tous les types d'aide et la fonction d'implémentation publics, exposant chaque détail de la gestion interne des tampons et des calculs de pas. Bien que cela aurait permis le repliement, cela aurait enfermé l'équipe dans la nécessité de maintenir ces types internes spécifiques comme une API stable pour toujours, empêchant le refactoring futur et encombrant l'interface publique avec des détails d'implémentation que les consommateurs ne devraient jamais toucher directement.
Une autre option envisagée était d'utiliser @inline(__always), qui en ligne agressivement le code au sein du même module mais ne pas exporter le corps de la fonction vers d'autres modules ; cela aurait permis de garder l'API propre mais n'aurait pas permis au compilateur client de spécialiser le générique T pour des types numériques spécifiques comme Float16 ou Double, laissant la surcharge d'appel au moment de l'exécution intacte et échouant à atteindre les objectifs de performance.
Les ingénieurs ont finalement marqué le point d'entrée avec @inlinable et annoté les structures de tampon interne et les aides arithmétiques avec @usableFromInline. Cette stratégie a exposé juste assez de détails d'implémentation au compilateur pour permettre une monomorphisation et un repliement complets aux sites d'appel des clients tout en gardant les symboles en dehors de la documentation publique. Le résultat a été que les applications clientes ont atteint des performances identiques à celles du code C manuellement déroulé, bien que la taille binaire du framework ait légèrement augmenté en raison de la duplication de code à travers les modules, et l'équipe a accepté que corriger la fonction nécessiterait que les clients recompilent.
Quelle est la distinction fondamentale entre @inlinable et @inline(__always) concernant les frontières inter-modules ?
@inlinable est un contrat d'interface de module qui écrit le corps de la fonction dans le fichier .swiftinterface, permettant au compilateur d'émettre l'implémentation directement dans les modules dépendants lors de leur compilation, ce qui est essentiel pour la spécialisation générique inter-modules. En revanche, @inline(__always) est simplement un indice d'optimisation pour l'unité de compilation locale ; il indique à l'optimiseur d'aplanir la pile d'appels au sein du module mais ne rend pas le corps accessible aux compilateurs externes, ce qui signifie que les modules clients invoquent toujours la fonction par une indirection résiliente et ne peuvent pas éliminer la surcharge d'appel générique.
Pourquoi Swift nécessite-t-il @usableFromInline pour les symboles internes référencés par des fonctions @inlinable plutôt que de simplement inférer la visibilité ?
Lorsqu'une fonction est intégrée dans un module client, le compilateur doit générer des instructions machine concrètes pour ce code au site d'appel, ce qui nécessite des métadonnées de type complètes et des adresses de symbole pour chaque entité référencée ; les symboles internal sont intentionnellement exclus de l'interface du module pour imposer l'encapsulation. @usableFromInline agit comme un niveau de visibilité spécial réservé au compilateur qui expose la définition du symbole dans le fichier d'interface sans la rendre accessible au code source client, satisfaisant les exigences de génération de code tout en maintenant la confidentialité au niveau source et en empêchant les fuites d'API accidentelles.
Comment l'adoption de @inlinable affecte-t-elle la stabilité de l'ABI et les caractéristiques de taille binaire d'une bibliothèque Swift ?
Marquer une fonction @inlinable intègre son implémentation dans l'ABI de la bibliothèque, ce qui signifie que tout changement apporté au corps de la fonction—comme corriger un bogue ou améliorer un algorithme—constitue un changement binaire défaillant qui nécessite que tous les modules clients soient recompilés pour observer la mise à jour, à la différence des fonctions résilientes où l'implémentation peut être échangée indépendamment. De plus, comme le compilateur duplique le corps de la fonction à chaque site d'appel dans tous les binaires clients plutôt que de référencer une seule adresse de bibliothèque partagée, @inlinable augmente considérablement la taille binaire totale de l'application finale, le rendant inapproprié pour des fonctions utilitaires grandes et appelées peu fréquemment.