Les types de valeur Swift standard s'appuient sur des copies implicites et ARC pour gérer les ressources allouées sur le tas, permettant aux valeurs d'être dupliquées librement à travers les frontières de fonction. En revanche, une structure déclarée avec ~Copyable (non copiée) interdit complètement la copie implicite, imposant une propriété unique. Lorsqu'une telle structure est passée à une fonction, Swift exige des annotations de propriété explicites : consuming transfère la propriété de manière permanente au destinataire, borrowing accorde un accès temporaire en lecture seule sans déplacer ou copier, et inout fournit un accès mutable exclusif temporaire. Ce modèle élimine la surcharge de ARC pour les ressources uniquement mobiles et garantit une sécurité à la compilation contre les erreurs d'utilisation après déplacement ou de double copie.
Nous construisions une application de trading haute fréquence où un paquet de données de marché de 2 Mo représentait un tampon DMA en espace noyau qui devait rester unique pour la cohérence et la performance.
Problème : Passer ce tampon entre les étapes de traitement (entrée réseau, validation, moteur de stratégie) sans dupliquer la mémoire sous-jacente ou déclencher le comptage de références dans le chemin critique. Les classes standard ont introduit une latence ARC inacceptable, tandis que les pointeurs non sécurisés risquaient des fuites de mémoire et des références pendantes.
Solution 1 : Classe avec comptage de références. Nous avons considéré d'encapsuler le tampon dans une classe avec un gestionnaire de déinitialisation. Les avantages incluaient une gestion de mémoire familière et un partage facile. Cependant, les inconvénients étaient sévères : chaque passage entre les composants déclenchait des opérations de maintien/libération atomiques qui détruisaient la localité du cache et violaient nos exigences de latence de 100 microsecondes.
Solution 2 : Pointeurs bruts non sécurisés. Utiliser UnsafeMutablePointer<UInt8> avec allocation manuelle évitait complètement ARC. Les avantages étaient l'absence de surcharge et un contrôle total. Les inconvénients incluaient l'absence de garanties de sécurité à la compilation : les développeurs pouvaient facilement libérer deux fois le tampon ou accéder à de la mémoire désallouée, conduisant à des pannes en production.
Solution 3 : Structure non copiée avec modificateurs de propriété. Nous avons défini struct MarketDataBuffer: ~Copyable contenant le pointeur. Les fonctions recevant le tampon utilisaient consuming pour prendre la propriété (par exemple, func process(_ buffer: consuming MarketDataBuffer)), tandis que les fonctions d'inspection utilisaient borrowing (par exemple, func validate(_ buffer: borrowing MarketDataBuffer)). Cela fournissait une application de la propriété unique à la compilation et zéro surcharge d'exécution.
Solution choisie et résultat : Nous avons choisi la Solution 3. Le résultat a été un pipeline de données déterministe où le compilateur empêchait les copies accidentelles et les erreurs d'utilisation après déplacement. Le système traitait les paquets sans trafic ARC et garantissait que le tampon DMA avait exactement un propriétaire logique à tout moment, améliorant considérablement la cohérence de latence.
Comment le marquage d'un paramètre de fonction comme consuming affecte-t-il la capacité de l'appelant à utiliser une valeur non copiée après le retour de la fonction ?
Lorsqu'un paramètre est marqué consuming, la fonction prend la propriété de la valeur à l'entrée. Pour un type ~Copyable, cela constitue un mouvement destructeur plutôt qu'une copie. L'appelant doit abandonner la valeur, et après l'appel de fonction, la variable d'origine devient non initialisée et inaccessible. Tenter d'y accéder entraîne une erreur de compilation. Cela impose une propriété linéaire, garantissant que la valeur a exactement un propriétaire pendant toute sa durée de vie. Pour les types copiables, consuming déclencherait une copie implicite pour satisfaire l'exigence, mais pour les types non copiables, aucune duplication ne se produit.
Pourquoi les types non copiables ne peuvent-ils pas être stockés dans des collections génériques standard comme Array dans les versions Swift antérieures à 6.0 ?
Avant Swift 6.0, les types génériques de la bibliothèque standard exigeaient implicitement que leurs paramètres de type se conforment à Copyable. Comme les types non copiables s'excluent explicitement de Copyable en utilisant la contrainte ~Copyable, ils violaient cette exigence implicite et ne pouvaient pas être stockés dans un Array ou un Optional. Swift 6.0 a introduit des génériques non copiables, permettant aux conteneurs de prendre en charge conditionnellement des éléments non copiables en faisant propaguer la contrainte ~Copyable. Cependant, des opérations comme append doivent utiliser des sémantiques consuming, et la collection elle-même devient non copiée si elle contient des éléments non copiables, nécessitant une gestion soigneuse de la propriété aux frontières de l'API.
Quelle est la différence entre le modificateur de paramètre borrowing et le modificateur traditionnel inout lorsqu'ils sont appliqués aux types non copiables ?
Le modificateur borrowing accorde un accès temporaire, immuable à la valeur sans transférer la propriété. L'appelant conserve la valeur et peut continuer à l'utiliser après le retour de la fonction, à condition qu'elle n'ait pas été consommée dans la fonction. En revanche, inout représente un emprunt mutable : il nécessite un accès exclusif, déplace temporairement la valeur dans la fonction pendant la durée de l'appel pour permettre la mutation, puis la ramène. Pour les types non copiables, borrowing est essentiel pour l'inspection en lecture seule sans abandonner la propriété, tandis que inout est nécessaire pour la modification. De manière cruciale, borrowing empêche la fonction de consommer ou de déplacer la valeur, tandis que inout garantit que la valeur revient à l'appelant dans un état valide, potentiellement modifié.