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 Lightman | 

Super de nous tenir au courant de cela.
J'aime les exemples avant/après.
😀

avatar raoolito | 

@Lightman

la programmation est toujours l’apanage de ceux ayant un diplome en mathématique :P
Et pourtant meme moi j’ai compris avec cet exemple hahaha !

avatar Florent Morin | 

@raoolito

Vous allez me vexer : j’ai un profil plutôt littéraire 😂

J’ai un Bac technologique car j’étais trop nul en maths.

avatar IceWizard | 

@FloMo

« J’ai un Bac technologique car j’étais trop nul en maths. »

C’est aussi mon cas !

avatar reborn | 

@IceWizard

Team bac techno 💪
Sauf que moi j’étais naze en français aussi 😐

avatar IceWizard | 

@reborn

« Team bac techno 💪
Sauf que moi j’étais naze en français aussi « 

Je faisais 5 fautes par ligne à l’époque ! C’est en apprenant par moi-même que j’ai progressé, hors du contexte scolaire. Même si j’ai encore des lacunes sur le sujet. Globalement l’école m’a appris à apprendre par moi-même !

(Et aussi grâce à un connard de psychologue scolaire qui m’a sorti du cycle normal pour m’envoyer apprendre à lire dans une section « spéciale «  où pendant 2 ans, j’ai juste appris à colorier des dessins et jouer avec des cubes, pour être ensuite re-injecté dans le cycle scolaire avec des enfants de mon âge, ayant suivis un cursus normal).

avatar YetOneOtherGit | 

@raoolito

"la programmation est toujours l’apanage de ceux ayant un diplome en mathématique"

Nope c’est assez proche de la philosophie sur bien des enjeux.

C’est avant toute chose de l’analyse / synthèse, de la sémantique et de la logique.

Un ouvrage de base pour faire découvrir aux « littéraires » les beautés de la chose informatique :

https://fr.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach_:_Les_Brins_d%27une_Guirlande_%C3%89ternelle

avatar Florent Morin | 

@YetOneOtherGit

C’est marrant ça. En effet, j’étais nul en maths, mais plutôt bon en philosophie. Comme quoi.

avatar DahuLArthropode | 

@FloMo

Les maths, ce n’est pas une seule discipline, c’est très varié. On peut aimer la logique, la géométrie, et être nul en trigonométrie ou en analyse. C’est d’ailleurs vrai aussi en philo: on peut adhérer à certaines branches, et être imperméable à d’autres. Et même en informatique : il y a tellement de couches, tellement de branches…
L’école induit souvent des goûts et des dégoûts en bloc pour une matière, et on peut tardivement se découvrir un intérêt pour ce qui nous avait paru ennuyeux ou inabordable.

avatar Cric | 

@DahuLArthropode

Ce que tu dits est plein de bon sens !

avatar Florent Morin | 

@DahuLArthropode

C’est vrai que dans mon cas, le milieu scolaire a été particulièrement néfaste.

Mais je pense que passé un certain âge, c’est trop long de s’y remettre pour que ça ai vraiment du sens.

Aujourd’hui, je « picore » des concepts ici et là que j’approfondis au besoin. Par exemple, les statistiques pour l’apprentissage automatique.

avatar DahuLArthropode | 

@FloMo

Oui, mais avec l’âge, on a justement le privilège de pouvoir aborder la discipline comme une culture, gratuitement, sans objectif de maîtrise, de performance, sans crainte du jugement. Je me mets à aimer des poèmes qui m’emmerdaient quand je devais les apprendre par cœur.
La programmation a été pour moi un loisir avant d’être un métier. Et en tant que métier, j’ai trouvé ça très chiant. Et maintenant, j’en refais un peu pour m’amuser.
J’imagine que les mots croisés ou les sudokus à plein temps, ce serait l’enfer.

avatar Derw | 

@YetOneOtherGit

« "la programmation est toujours l’apanage de ceux ayant un diplome en mathématique"

Nope c’est assez proche de la philosophie sur bien des enjeux. »

Dans la vraie vie, oui. Mais dans les cursus scolaires, malheureusement, pas encore. Je suis bien placé pour le savoir, j’ai un fils en 1ère qui a pris pour ses 3 options : maths, physique, NSI (informatique) et il est bon partout, mais c’est la NSI qu’il préfère. Il est donc probable qu’il se dirige vers des études d’ingénieurs en informatique. Comme le prévoit les programmes il doit laisser tomber une de ces 3 options en terminale, mais malheureusement, tout le monde semble considérer qu’il doit laissé tomber l’informatique pour devenir informaticien. Et je ne parle même pas de cette habitude de mettre les plus mauvais profs de français et de philo du lycée aux scientifiques…

avatar Cric | 

@YetOneOtherGit

"Nope c’est assez proche de la philosophie sur bien des enjeux."

Intéressant ce que tu dits car j’étais nul en philo ce qui ne m’a pas empêché de faire une partie de mes études dans le domaine informatique.
Je vais lire attentivement le texte via le lien que tu as donné 🙏

avatar YetOneOtherGit | 

@Cric

"Je vais lire attentivement le texte via le lien que tu as donné 🙏"

C’est un pure chef-d’œuvre qui demande quelque efforts de lecture 😉

avatar Cric | 

@YetOneOtherGit

Et du coup ça m’a donné envie de le lire 😎

avatar DahuLArthropode | 

@YetOneOtherGit

Ouais... pour le coup, le théorème de Gödel, c’est bien des maths, et des pointues (même si Douglas Hofstadter rend ça très accessible). Et Bach et Escher, c’est aussi les maths qui contribuent à la beauté. Et le bouquin lui-même est un monument de l’auto-référence et de la mise en abîme.
Je me rappelle un chapitre fascinant du bouquin, avec des tests de QI très simples du type « trouver l’intrus », où il invite le lecteur à se regarder penser. J’ai vu que j’étais incapable de programmer la résolution du moindre de ces problèmes alors que tous étaient basiques pour un humain. Et mon rayon, c’était la programmation en logique (il faut dire qu’à l’époque, je croyais qu’un ordinateur ne saurait jamais jouer au go ou reconnaître un visage: je ne devais pas être très bon dans mon rayon).
Tout ça pour dire quand même que la beauté dans Gödel-Escher-Bach vient de la récursion et qu’elle est bien mathématique et logique.
Mais il me semble que la logique était autrefois une branche de la philosophie.

avatar YetOneOtherGit | 

@DahuLArthropode

"Mais il me semble que la logique était autrefois une branche de la philosophie."

Yep et l’ouvrage est écrit d’une manière ne nécessitant pas de pré requis mathématiques et plaisante aux « littéraires » 😉

avatar YetOneOtherGit | 

@DahuLArthropode

"Mais il me semble que la logique était autrefois une branche de la philosophie"

Me grand Bertrand Russell est le seul grand mathématicien récipiendaire du Nobel (Littérature)

Quasiment tous les « vrais » mathématiciens que je connais sont férus de philosophie 😉

avatar YetOneOtherGit | 

@DahuLArthropode

"pour le coup, le théorème de Gödel, c’est bien des maths, et des pointues (même si Douglas Hofstadter rend ça très accessible). Et Bach et Escher, c’est aussi les maths qui contribuent à la beauté."

C’est un des intérêts de la somme d’Hofstadter montrer à un lectorat de non mathématiciens les liens profonds entre des domaines qui peuvent sembler très éloignés 😉

avatar IceWizard | 

@raoolito

« la programmation est toujours l’apanage de ceux ayant un diplome en mathématique :P « 

J’ai commencé à comprendre l’intérêt des maths, le jour où j’ai vu qu’une équation du second degré, permettait de donner une allure réaliste à la trajectoire d’un missile, dans un jeu vidéo que je développais en Basic, après avoir quitté l’école !

avatar YetOneOtherGit | 

@IceWizard

Et oui l’équation cartésienne d’une trajectoire balistique est une fonction polynomiale de degré deux dont les coefficients sont fonction de la vitesse initiale, de l’angle de tire et de l’accélération de la pesanteur.

Ce qui est bien en informatique c’est que bien des solutions appliquées reposent sur de vieilles mathématiques.

Le champ des sciences informatiques reposant sur une mathématique pointue et relativement récente, dépassant un niveau de taupe, existe mais est assez réduit.

avatar hawker | 

La progra, c'est pas uniquement pour les bon en maths, sauf si tu code du code des kernel de logiciels qui font des taches complexes.
C'est surtout et avant tout de la logique et de l'organisation.
Une personne nul en math mais méticuleuse et organisée sera un bien meilleur programmeur que quelqu'un bon en math mais très désorganisé et inconsistent.
Je connais des programmeurs qui pondent du conde ultra complex et dégueulasse et qui se prennent pour des genies et d'autre qui font tout au plus simple pour des tache moins complexes, mais des deux, celui que je garde, c'est pas le premier........

avatar wataru | 

depuis le temps que l’on attend une version native de « async » sur Swift. Personnellement quand je jongle entre TypeScript/Dart/Swift je pour rend compte des lacunes du Swift sur ce genre de point précis.

avatar BeePotato | 

Au vu des discussions à ce sujet sur les forums de Swift, il me paraît très optimiste d’espérer une sortie de Swift 6 en 2021. Ça semble s’orienter plutôt vers un 5.5 intégrant la première version de ce qui a été proposé pour la concurrence.

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

CONNEXION UTILISATEUR