Swift : des petits changements en 5.4 avant l'arrivée de Swift 6

Florent Morin |

Suivant Swift 5.3 en septembre, Apple prépare la sortie de Swift 5.4 et même au-delà, avec Swift 6 qui pourrait être officialisé avec la WWDC. Swift 5.4 est une mise à jour mineure du langage, mais les améliorations attendues pourront bousculer le quotidien des développeurs.

Les petits changements de Swift 5.4

Apple a annoncé la transition vers Swift 5.4 le 11 novembre dernier. Cette version aura un cycle de développement spécifique, dissocié du reste de Swift et elle intégrera uniquement ses propres évolutions. Tous les projets sous-jacents, comme le gestionnaire de paquets Swift Package Manager, seront synchronisés sur cette version dans les jours qui viennent.

Si tout va bien, Swift 5.4 devrait sortir dans une première bêta en même temps que Xcode 12.4 dans les prochaines semaines. D’ici là, on peut avoir un aperçu de ce qui nous attend grâce au processus de développement open source et au suivi des évolutions du langage. Voici trois évolutions intéressantes pour les développeurs.

La proposition SE-0287 a pour but d’améliorer le chaînage des instructions, une opération très utilisée en Swift. L’idée est de l’autoriser dès l’initialisation d’un composant. Voici à quoi cela ressemblera côté code :

Initialisation d’un composant, avant et après Swift 5.4

La proposition SE-0289 est un peu plus complexe, mais elle s’appuie sur un principe utilisé abondamment par SwiftUI. Les « result builders » (qui étaient nommés jusque-là « ‌function builders ») sont des fonctions qui produisent un résultat implicite. On les utilise aujourd’hui pour générer des interfaces avec la syntaxe déclarative de SwiftUI, cela pourra aussi être utilisé pour générer du HTML sur les serveurs, voire des interfaces en UIKit ou AppKit.

VStack, Image et Text dans SwiftUI

L’évolution proposée SE-0284 ajoute de la souplesse pour gérer les paramètres d’une fonction. Aujourd’hui, si on a plusieurs paramètres à passer dans une fonction, on peut le faire sous la forme d’un tableau ou d’un nombre variable de paramètres. Mais cette dernière possibilité est si contraignante qu’elle est rarement utilisée. Avec cette proposition, elle devrait devenir plus pratique à utiliser.

Les paramètres d’une fonction, sous la forme d’un tableau puis en paramètres variables avec Swift 5.4

En route vers Swift 6

Swift 6 a été annoncé il y a presque un an. Plusieurs fonctions ont été déployées progressivement, comme la prise en charge de nouvelles plateformes en dehors de celles d’Apple qui a commencé avec Swift 5.3 et Windows. Avec Swift 6, d’autres plateformes pourraient rejoindre la course. On parle d’une version Web Assembly, une adaptée aux Raspberry Pi, une pour OpenBSD et pourquoi pas une prise en charge officielle d’Android (le travail a commencé il y a quelques années).

De nouvelles fonctionnalités ont aussi été mises en chantier récemment : à six mois de la WWDC 2021, cela tombe bien. La bibliothèque standard de Swift devrait évoluer et on peut s’attendre à quelques améliorations du confort des développeurs que vous pourrez découvrir au travers de l’outil de suivi des évolutions de Swift. Mais s’il y a bien un changement qui était particulièrement attendu, c’est l’intégration de async/await pour simplifier la gestion des tâches parallèles.

C’est un élément courant pour un langage de développement, mais qui n’était pas disponible en Swift jusque-là. Son ajout permettra de simplifier les opérations qui peuvent être menées en parallèle, très fréquentes dans un programme. Pour illustrer cette fonctionnalité, nous allons partir de l’exemple fourni par Swift avec le téléchargement et la manipulation d’images, deux tâches qui sont des opérations asynchrones par excellence. Voici ce que cela donne aujourd’hui :

Des blocs de code, imbriqués dans d’autres blocs de code…

Cette complexité entraînait un risque d’erreur permanent, surtout quand le programme grossit. Grâce à l’ajout de cette nouvelle fonction, la syntaxe pourra être beaucoup plus simple et claire :

La syntaxe de async et await.

Autre avantage, c’est compatible avec Objective-C, ce qui permet d’intégrer plus simplement le code à des projets existants. Associée à cette gestion du code asynchrone, l’exécution de tâches en parallèle avec une autre proposition pour les organiser. Une syntaxe adaptée sera ajoutée à Swift pour répondre à ces nouveaux besoins.

On peut noter l’arrivée des actors, un procédé également présent dans d’autres langages qui permet d’éviter que deux tâches parallèles tentent de modifier au même moment une même donnée. Si c’est le cas, l’app risque de planter ou au minimum de provoquer un comportement inattendu et ces bugs sont particulièrement difficiles à corriger, car ces situations sont complexes à reproduire.

Apple devrait adapter ses propres frameworks à ces évolutions de Swift. L’optimisation des tâches parallèles est un point important pour les performances et on peut imaginer que le constructeur fera tout pour que les puces Apple Silicon en profitent. On en saura sans doute plus à la WWDC, ce qui laisse six mois pour se préparer aux futures évolutions du langage.

avatar hawker | 

J'ai vraiment du mal avec ces syntaxes ou tout n'est pas type, name, value et voila.
J'aurais aime que ca garde plus le style c.

avatar BeePotato | 

@ hawker : « J'ai vraiment du mal avec ces syntaxes ou tout n'est pas type, name, value et voila. »

Ben là c’est juste name [type] value, c’est tout. :-)
Avec juste le fait que le type apparaît rarement, car il est souvent présent implicitement, voire explicitement, dans l’expression de la valeur.

« J'aurais aime que ca garde plus le style c. »

Je peux comprendre ça. :-)
Mais à partir du moment où l’inférence de type fait que le type n’est plus que rarement écrit, il est plus pratique qu’il soit après le nom, ce qui permet plus de cohérence : on a toujours un nom en première position, au lieu d’avoir parfois un type, parfois un nom. Une alternative est l’approche du « auto » en C++, mais ce n’est pas plus plaisant à mon avis.
Cela dit, rien en Swift ne t’interdit d’écrire systématiquement le type (comme dans l’exemple qui est donné ici pour le SE-0287, et qui à mon avis ne met pas bien en valeur l’apport de ce changement).
Mais franchement, l’inférence allège de nombreuses lignes de code et évite beaucoup de répétitions. À l’usage, c’est un plaisir. :-)

avatar YetOneOtherGit | 

@hawker

"J'ai vraiment du mal avec ces syntaxes ou tout n'est pas type, name, value et voila."

C’est le poids habitudes rien de plus 😉

L’inference de type est une avancée présente dans nombre de langages modernes et elle a largement fait ses preuves.

Et c’est loin d’être l’essentiel de Swift d’ailleurs.

Il y a pour moi une forme de gymnastique intellectuelle à laquelle doit se consacrer un dev qui ne veut pas se scléroser dans un langage ou un seul des paradigmes proposés par un langage : sortir le plus régulièrement de la zone de confort pour que l’adaptation à la perte de repaires devienne naturelle.

Et on peut être confronté à ces enjeux au sein même d’un langage. Par exemple C++ qui a énormément évolué dans son histoire et qui est multi-paradigmes, beaucoup de dev C++ travaille « à l’ancienne » et ne maîtrise qu’une petite part de ce qu’offre les itération récente du langage (Sans parler de ceux qui utilisent C++ mais font en fait du C batardisé d’une vague approche objet)

Bref, il faut pour moi régulièrement se confronter à l’inconnu pour apprendre à ne plus être déstabilisé.

Pour finir un langage intéressant pour justement se confronter à une approche déstabilisante est actuellement Rust que je conseil vraiment d’explorer pour entretenir l’ouverture des chakra.

Et évidemment se confronter à un véritable langage fonctionnel reste un passage obligé pour donner un peu de ductilité à son esprit 😉

avatar Rez2a | 

@YetOneOtherGit

« sortir le plus régulièrement de la zone de confort pour que l’adaptation à la perte de repaires devienne naturelle »

« Repères », sinon c’est un malheureux développeur SDF que vous décrivez 😁

avatar YetOneOtherGit | 

@Rez2a

Je sors de ma zone de confort chaque fois que j’écris 🥴😉

avatar unixorn | 

« Son ajout permettra de simplifier les opérations qui peuvent être menées en parallèle »

C’est faux. Comme son nom l’indique, async/await permet de gérer plus facilement* les opérations asynchrones, par exemple une requête web ou un accès au système de fichier. La question du parallélisme n’est pas la même, et est géré par d’autres techniques commes les threads ou Grand Central Dispatch.

* en théorie, car en pratique le fait que ça contamine vers le haut les fonctions appellantes est assez embêtant.

avatar BeePotato | 

@ unixorn : « C’est faux. »

Pas d’accord.
Async/await n’est pas dédié à l’exécution concurrente — et il y a d’ailleurs des propositions séparées pour cette partie sur Swift Evolution. Mais en facilitant l’usage de fonctions asynchrones, async/await simplifie effectivement de nombreux cas d’exécution concurrente.

avatar YetOneOtherGit | 

@BeePotato

"Mais en facilitant l’usage de fonctions asynchrones, async/await simplifie effectivement de nombreux cas d’exécution concurrente."

👍

avatar Cclleemm | 

Et sinon du coté de SwiftUI, est-il à l'abandon ? Peu de nouvelles et encore pas mal de manques/bugs...

avatar BeePotato | 

@ Cclleemm : « Et sinon du coté de SwiftUI, est-il à l'abandon ? Peu de nouvelles »

?!?
SwiftUI a nettement progressé avec Big Sur, pourtant.

avatar Cclleemm | 

@BeePotato

Au niveau du langage il y a peu (pas) de communication sur la roadmap et sur les derniers changements apportés au langage. C’est vrai que ça c’est amélioré (surtout au niveau de l’intégration OS en effet) mais franchement il y a plein de problèmes encore sur certains composants avec des bugs et d’autres non gérés (a intégrer via UIKit du coup)

avatar BeePotato | 

@ Cclleemm :
Il y a des bugs et il manque encore des choses à SwiftUI pour être à égalité avec AppKit et UIKit, c’est sûr. Mais les ajouts faits avec Big Sur le rendent nettement plus utilisable qu’auparavant et ne donnent pas du tout l’impression d’un abandon.
En revanche, c’est un framework d’Apple intégré à ses OS : ça signifie qu’en termes de communication, il ne faut pas espérer la moindre roadmap, et que les avancées sont juste livrées en bloc une fois par an, à la WWDC.

Il ne faut pas espérer une visibilité similaire à ce qu’on peut avoir pour Swift lui-même. Ça ne signifie pas pour autant un abandon.

avatar eckri | 

swift sur ipados ou rien du tout

Pages

CONNEXION UTILISATEUR