Fermer le menu

La stabilité du code source validée pour Swift 4

Nicolas Furno | | 10:00 |  22

Swift 4, la prochaine évolution majeure du langage d’Apple, doit être présentée au mois de juin, lors de la WWDC 2017. L’un des gros enjeux pour cette version était la stabilité, à la fois du code source et des ABI comme nous vous l’expliquions précédemment. Cet objectif sera partiellement rempli cette année, puisque seule la stabilité du code source est annoncée.

Voici à quoi ressemblent quelques lignes de code en Swift.

Les développeurs n’auront pas à mettre à jour tout le code source de leurs apps pour passer de Swift 3 à Swift 4, même si la nouvelle version n’est pas identique à l’ancienne pour sa syntaxe. Il y a du nouveau dans la gestion du texte (les détails sont disponibles à cette adresse) et il faudra mettre à jour certains éléments. Néanmoins, la stabilité du code source est assurée par le compilateur qui saura gérer les deux syntaxes.

En théorie, tout sera transparent pour le développeur qui pourra utiliser indifféremment la syntaxe de Swift 3 ou celle de Swift 4, y compris au sein d’un même projet. Par ailleurs, les changements apportés restent bien moins importants que lors des précédentes mises à jour et on imagine que le travail d’adaptation sera minime. Mais encore une fois, à partir de ce moment, le code source doit être compatible avec toutes les versions de Swift, c’est le principe de la stabilité.

La stabilité ABI (Application Binary Interface) était également un des objectifs pour Swift 4, mais elle a été officiellement repoussée. Une partie du travail a été effectuée, mais il reste encore beaucoup de choses à faire apparemment, trop pour être prêt d’ici la fin de l’année. Pour le moment, Apple ne parle pas de Swift 5, mais de Swift 4, stage 2. Cela changera peut-être au cours des prochains mois.

Voici à quoi ressemblent les ABI stockées obligatoirement dans chaque app développée en Swift. Ce sera toujours le cas avec Swift 4. Cliquer pour agrandir

Swift 4 sera présenté en juin, mais sa sortie finalisée est prévue d’ici la fin de l’année. Les développeurs devraient pouvoir l’utiliser en bêta dès la WWDC, probablement avec une nouvelle version de Xcode pour l’accompagner.

Catégories: 

Les derniers dossiers

Ailleurs sur le Web


22 Commentaires Signaler un abus dans les commentaires

avatar RedMak 17/02/2017 - 10:08 via iGeneration pour iOS

C'est deja une bonne étape 👌

avatar maatthieu 17/02/2017 - 10:55 (edité)

J'ai l'impression d'être le seul à trouver que les évolutions du swift 2 vers 3 sont bizzards et alourdissent la syntaxe.
ex :
- l'underscore quasi-systèmatique,
- "open" au lieu de "public" (java, php et beaucoup d'autres utilisent "public" donc pourquoi changer ?)
- les mots-clés avec des @ plus nombreux
qu'en pensez-vous ?

avatar iPop 17/02/2017 - 11:41 via iGeneration pour iOS

@maatthieu

bizzards je ne sais pas mais bizarre sûrement.



avatar JeromeC 17/02/2017 - 13:47

Non, rien de bizarre.
- les _ sont apparu plus nombreux en version 2.0 parce que contrairement à la version précedente, le premier paramètre n'était plus traité différemment. Depuis la 2.0, le premier paramètre est comme les autres, avec un nom externe et un nom interne. La version 3.0 a au contraire diminué le nombre de méthodes à utiliser le _ en leur donnant un nom externe.

- public n'a pas disparu. il est même conseillé à open. open signifie que la classe peut être surchargée. Une classe public est donc visible de l'extérieur mais ne peut plus être surchargée.

Comme dit souvent, la version 3.0 est celle qui aurait du être la 1.0, mais un choix à été fait de sortir swift en l'état avec un gros warning disant que la syntaxe allait évoluer.

avatar C1rc3@0rc 17/02/2017 - 23:35

@JeromeC

«Comme dit souvent, la version 3.0 est celle qui aurait du être la 1.0, mais un choix à été fait de sortir swift en l'état avec un gros warning disant que la syntaxe allait évoluer.»

Je pense plutot qu'Apple a fait une petite erreur d'ecriture des numero de versions:
1 => 0.1
2 => 0.2
3 => 0.3
4 => 0.4
...
Maintenant on va avoir en plus une evolution avec la 0.3 et la 0.4 en parallele. Ensuite ce sera quoi, 0.3, 04 et 0.5 que le compilo prendra en compte et pendant combien de temps? L'obsolescence d'une version sera decretée au bout de combien de temps: 3 ans, 5 ans?

Python qui est sacrement plus coherent et unifié a décrété l'obsolescence de la V2 pour 2020, soit 12 ans apres la sortie de la V3!

Maintenant quel sera le vrai numero de sortie de beta 0.6, 0.7 ou 0.9...
Toujours est il qu'aujourd'hui si on prevoit un projet de developpement un peu important et qui doit etre maintenu plus de 2 ans, ben faut oublier Swift et programmer en Objective-C!

Enfin avoir une syntaxe stabilisée pour un 0.5 c'est deja pas mal.

avatar creatix 18/02/2017 - 08:44 via iGeneration pour iOS

@C1rc3@0rc

Je suis d'accord avec ces remarques, quand un client se réveille tous les 2 ans, devoir tout migrer dans la version actuelle de Swift c'est pas réaliste.
Surtout si c'est pour des bricoles à chaque fois. Xcode propose une migration du code mais pas sur que ca soit suffisant et surtout, les librairies aurons évoluée et devront être mis à jour.
Le Swift c'est plus cool que l'obj-c mais ça bouge trop vite malheureusement ( pour des projets amené à être mis à jour assez rarement)

avatar BeePotato 17/02/2017 - 10:58

« Pour le moment, Apple ne parle pas de Swift 5, mais de Swift 4, stage 2. Cela changera peut-être au cours des prochains mois. »

Une petite clarification : depuis le début, le développement de Swift 4 a été prévu en deux phases. La première se concentrait sur les changements affectant la stabilité (histoire de tous les intégrer et pouvoir donc, après ça, déclarer la syntaxe et l’ABI stables). La deuxième se focalise sur les autres modifications, celles n’ayant pas d’impact sur la stabilité.
La première phase est arrivée à son terme (mais avec la conclusion qu’il était encore trop tôt pour proclamer la stabilité de l’ABI), il est donc temps pour la deuxième phase de débuter, comme prévu dans le calendrier.
Ce n’est qu’après cette deuxième phase que commencera le travail sur Swift 5 (en parallèle de la finalisation de la version 4).

avatar malcolmZ07 17/02/2017 - 11:19 via iGeneration pour iOS

@BeePotato

+1
Commentaire très instructifs

avatar iGeek07 17/02/2017 - 15:29 via iGeneration pour iOS (edité)

@BeePotato

Même si la phase 1 était prévue pour réfléchir et planifier la stabilité, elle n'aurait pas été atteinte avant que certaines fonctionnalités très importantes ne soient développées : les generics, la façon de gérer les String etc.

avatar BeePotato 17/02/2017 - 16:03 (edité)

@ iGeek07 : Oui, espérer vraiment atteindre la stabilité à l’issue de cette phase 1 était illusoire. Mais se fixer ça comme objectif était tout de même une bonne idée, forçant une réflexion poussée sur le sujet.

avatar ovea 17/02/2017 - 11:57 via iGeneration pour iOS

Alors, ça avance la FRP qui swift ?

avatar FatB 17/02/2017 - 12:14

Vraie question de la part de quelqu'un qui code toujours en objective-c : n'est-il pas urgent d'attendre ?Qu'en pensez-vous ?

avatar Domsware 17/02/2017 - 12:20

Attendre quoi ?
Swift est mature, stable et exploité commercialement.
Le changement de langage est une opportunité pour dépoussiérer et mettre à jour ses connaissances.

avatar C1rc3@0rc 17/02/2017 - 23:18

Si tu fais des petits projets artisanaux (1 dev et un graphiste) pour un développement complet de moins de 6 mois et pour un produit qui ne sera pas maintenu, c'est jouable en Swift et a condition de coller totalement aux guidelines d'Apple. Pour le reste c'est irréaliste ou irresponsable.

J'imagine pas une équipe de dev qui va construire des librairies avec les centaines de fonctions qui va devoir mettre a jour les invocations et les réalisations juste pour des histoires de syntaxes inconsistantes d'un an sur l'autre...
Et en plus faut se rendre compte du travail de chasse au bug dans un environnent inconsistant rien qu'au niveau syntaxique.


" et Joe, t'as resolu les bug 5230 ?"
" oui, mais on des en stage 49, on a changé la syntaxe pour swift 4"
" et je fait comment moi, le projet est en swift 3, vous prevoyez un correction pour quand"
" pas prevu, on commence a passer les code en swift 5 a la fin de l'annee"
" hein deja, mais on aura jamais le temps de migrer le projet de notre coté"
" ben oui, mais la version 5 est deja sortie depuis 36 mois et Apple annonce une grosse maj pour la prochaine"
" ben on fait quoi? La lib est buggué, on peut pas sortir un mise a jour payante qui a les memes bug"
" promettez un patch et refaites le projet de zero en version 5, vous annoncez du retard et ça passe "
" hein mais on a pour au moins un an avec tout ce qu'il faut revoir, et vous serez en v6"
" ben ça j'avais dit qu'il fallait faire le projet en Obj-C des le depart..."

On a un exemple tres realiste avec Python qui pourtant n'a introduit une incompatibilité syntaxique qu'en 8 ans et encore qui est infiniment plus legere que celles de Swift: il y a encore des librairies cles qui vont obliger aujourd'hui de faire un projet en Python 2 et pas en Python 3 parce que la librairies n'a pas ete adaptée a Python 3 alors que Python 3 est disponible depuis 5 ans !!!

avatar RedMak 17/02/2017 - 13:01 via iGeneration pour iOS

@FatB

Apres 5 ans de dev en objC le passage à swift 2 puis à swift 3 s'est passé en douceur, ca peut être ch**** de sortir de ca zone de confort c vrai mais c'est pas si dure que ça.
Je trouve qu'il est vraiment temps de passer à swift (mm si de mon coté j'aime plus objC)

avatar FatB 17/02/2017 - 14:23

Merci pour la réponse. Sortir de sa zone de confort ne me gène pas tant que ça, c'est même le truc sympa dans la vie de dev, mais je pensais surtout à la maturité du langage, qui a quand même pas mal changé entre la v2 et la v3, si j'ai bien compris. Allez, dès que Swift 4 sort, j'attaque :)

avatar BeePotato 17/02/2017 - 15:58

@ FatB : « Allez, dès que Swift 4 sort, j'attaque :) »

Même pas besoin d’attendre Swift 4. Les évolutions syntaxiques par rapport au 3 seront mineures. Il est donc possible de se mettre à Swift avec la version actuelle sans craindre que ce soit une perte de temps.

Pour répondre à ta question initiale, donc : non, il n’y a plus besoin d’attendre — sans qu’il y ait encore, pour l’instant, d’obligation de se mettre à Swift (mais autant s’y mettre tranquillement, avant que cette obligation arrive).

avatar ovea 17/02/2017 - 12:50 via iGeneration pour iOS (edité)

Si la programmation des interfaces graphiques a bien posé des problématiques non résolus à ce jour, son paradigme a largement fait évoluer l'informatique.
Swift par la même occasion doit avancer et intégrer à la preuve de programme la gestion des effets de bord par l'utilisateur dans un style très épuré …
(propagation des valeurs, quand tu nous tiens)

avatar C1rc3@0rc 17/02/2017 - 23:29

Ca n'a pas de sens ce que tu ecris.

Swift n'a rien a voir avec la conception d'interface graphique, c'est un langage generique.

Et Swift a une syntaxe qui se complexifie a chaque version et qui est inconsistante d'une version a l'autre. En plus on est dans du multiparadigme, donc les preuves doivent prendre en compte le mixage de ses paradigmes. A moins d'une IA qui reconçoit le programme entièrement je vois pas comment c'est possible aujourd'hui.

avatar ovea 18/02/2017 - 06:48 via iGeneration pour iOS

«Ca n'a pas de sens ce que tu ecris.

Swift n'a rien a voir avec la conception d'interface graphique, c'est un langage generique.

Et Swift … syntaxe … multiparadigme++, … preuves … mixage … paradigmes😡. IA-- qui reconçoit le programme entièrement je vois pas comment c'est possible aujourd'hui.»

Bon ça veut dire que la gestion des évènements ne fait pas partie encore de Swift … d'une façon syntaxique élégante 💩

C'est mort pour avancer dans le Patron Observateur !

avatar ovea 18/02/2017 - 14:39 via iGeneration pour iOS (edité)

@ovea
«IMPLEMENTING EVENTS IN SWIFT
Colin Eberhardt · 5th Feb 2015 · 6 min read 8 0

Cocoa has a number of techniques that allow classes to collaborate in a loosed-coupled fashion via some form of notification, including target-action, the delegate pattern, NSNotification and KVO. These are all forms of the classic Observer Pattern, yet all are different implementations, and each have their own failings. KVO is cumbersome, the delegate pattern only permits a single observer … However this post isn’t a rant about Cocoa, so enough of that ;-)»
http://blog.scottlogic.com/2015/02/05/swift-events.html

Et puis on se fou de la syntaxe quand le langage est fait pour l'étendre afin d'écrire des programmes avec une syntaxe adaptée au problème à résoudre !

Ici la gestion des événements dans Swift qui se balade entre les frameworks et le langage, sans que se dernier offre une possibilité de synthèse … >-(

avatar C1rc3@0rc 18/02/2017 - 22:54

Ben avec NSNotification et KVO tu parles de Cocoa, pas de Swift. Ca vaut autant pour Objective-C...

«Bon ça veut dire que la gestion des évènements ne fait pas partie encore de Swift … d'une façon syntaxique élégante 💩 »
Tu veux dire quoi par la ?
J'ai pas vu que Swift integre ou veuille integrer le paradigme d'agent ou plus basiquement les briques du modele a prototype.

«Et puis on se fou de la syntaxe quand le langage est fait pour l'étendre afin d'écrire des programmes avec une syntaxe adaptée au problème à résoudre ! »

Je comprend pas cette phrase, il manque quelque chose.

«Ici la gestion des événements dans Swift qui se balade entre les frameworks et le langage, sans que se dernier offre une possibilité de synthèse … >-(»

La aussi la phrase n'a pas de sens.
Swift se balade entre les frameworks et le langage ??? quel langage?
Une synthese de quoi ?