Discussion :

[Michael Guilloux]

Swift : les boucles for de style C seront supprimées dans le langage de programmation d’Apple
À partir de la version 3.0

Swift, le langage de programmation multiparadigme d’Apple, et depuis peu open source, a été dévoilé il y a moins de deux ans, mais il a su gagner en popularité auprès des développeurs. Il lui est en effet reconnu de faciliter la construction de logiciels qui sont rapides et sûrs par conception. En plus de cet avantage, la croissance de Swift peut être en partie imputée à sa courbe d’apprentissage courte grâce à une certaine familiarité pour les développeurs issus de certains langages populaires. À titre d’exemple, rappelons que le langage d’Apple utilise de nombreuses déclarations familières pour les développeurs C. C’est le cas notamment des boucles for et while qui permettent d’exécuter une tâche plusieurs fois.

En plus de la boucle for traditionnelle héritée du langage C, Swift ajoute une boucle for-in qui facilite les itérations sur des tableaux, des dictionnaires, des plages, des chaînes et bien d’autres séquences. La boucle for-in exécute un ensemble d’actions pour chaque élément dans une séquence. En ce qui concerne la boucle for, elle exécute un ensemble d’actions jusqu’à ce qu’une condition spécifique soit remplie, typiquement par incrémentation d’un compteur à chaque fois que la boucle se termine.

Exemples d’utilisations de for et for-in pour afficher les cinq premières entrées d’une table de multiplication par 5 :

Avec la boucle for-in

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
for index in 1...5 {
    print("\(index) times 5 is \(index * 5)")
}
// 1 times 5 is 5
// 2 times 5 is 10
// 3 times 5 is 15
// 4 times 5 is 20
// 5 times 5 is 25

Avec la boucle for

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
for var index = 1; index < 6; ++index {
    print("\(index) times 5 is \(index * 5)")
}
// 1 times 5 is 5
// 2 times 5 is 10
// 3 times 5 is 15
// 4 times 5 is 20
// 5 times 5 is 25

Si la boucle for-in est beaucoup plus utilisée que la boucle for dans Swift, la dernière présente par contre certains avantages que n’offre pas la boucle for-in. Toutefois, ces avantages semblent ne pas être aussi incontournables pour justifier l’implémentation de la boucle for de style C dans le langage Swift, d’après un utilisateur. Ce dernier a alors fait une proposition sur GitHub dans laquelle il demande de « supprimer les boucles for de style C avec des conditions et incrémenteurs ».

Après avoir examiné la requête du 7 au 10 décembre, l’équipe d’examinateurs a accepté la requête et décidé de supprimer les boucles for dans la version 3.0 de Swift. En ce qui concerne la version 2.2 en cours de développement, il y sera introduit un avertissement pour indiquer aux utilisateurs que les boucles de style C seront supprimées, avant que la mesure soit effectivement appliquée dans Swift 3.0.

Le comité d’analyse s’accorde sur le fait que les boucles for de style C sont assez rares dans le code Swift et qu’en plus, la plupart des utilisations existantes pourraient être mieux écrites en boucles for-in. Toutefois, il reconnaît qu’il y a des domaines en particulier où le retrait des boucles for de style C pourrait causer des problèmes.

D’abord, il existe des situations où les boucles sont difficiles à exprimer clairement avec for-in. C’est le cas notamment des décomptes. Pour corriger ce problème, la solution envisagée consiste à apporter des améliorations dans la bibliothèque Standard.

Un autre problème que pourrait causer la suppression des boucles for est qu’il existe encore des utilisations avancées de ces boucles qui sont difficiles à exprimer autrement. Le comité d’examen estime ici que ces utilisations plus avancées ne sont pas assez fréquentes pour justifier le maintien des boucles for de style C dans le langage.

Le dernier problème est que la performance de la boucle for-in est à la traîne par rapport à celle des boucles for de style C dans certains cas. L’amélioration de l’optimiseur a été trouvée comme une solution pour combler cet écart de performance. Le comité d’examen estime par ailleurs que les boucles while sont aussi une solution acceptable pour les codes à performance critique où l’optimiseur ne parvient pas à éliminer les abstractions utilisées dans la boucle for-in.

Sources : Swift-evolution-announce mailing list, GitHub

Et vous ?

Que pensez-vous de la suppression des boucles for de style C dans Swift ?
Les solutions proposées peuvent-elles combler la suppression de ces boucles ?

Voir aussi

Swift est maintenant open source, le code source du langage de programmation d’Apple est disponible sur GitHub

[MikeRowSoft]

Maintenant il n'est plus possible de mettre une fonction(action){... return value;} une fois arrivé en fin de boucle.
Dans l'exemple ++index ou index++.

Se n'est donc plus une boucle /*while(fonction(action){... return value;})*/ ou do-while.

Donc c'est pédagogiquement correct mais répétitif surtout pour un algorithme.

Des GOTO il y en a? (là encore c'est un peu pareil... mais avec des if(a()) b(); else d(); ou if(a())b() if(!a())d(); en non optimisé et sans influence temporelle vis-à-vis de la valeur délivré par a()[n'est pas dans un buffer cache, donc pas par temps réel ou ayant des interruptions déclarant la "fraicheur" de l'information])

[Remarque]
La modélisation objet dans tous sa? (L'objet ne laissant pas autres que lui ou hérité manipuler ses variables dans les cas strictes.)
La parti "visible" des librairies peut sûrement sent passer...

[gstratege]

C'est quoi les avantages de ce langage ??

[MikeRowSoft]

@stratege, c'est sûrement pour être plus accessible en lecture et partage de codes sources pour le développement et peut-être ne pas trop dépendre du hardware.
Machine virtuelle te revoilà. webbrower->show()

[SofEvans]

Il n'y a que moi à n'avoir jamais vraiment compris ce que MikeRowSoft écrit ?

Sinon, je trouve dommage que la boucle for disparaisse complètement.
D'un certain point de vue, la boucle for en langage C est tout aussi "supprimable" car la boucle while fait très bien le job, mais bon ...
pour ceux qui connaisse swift mieux que moi, est-ce que for-in peut complément remplacer for ?

[Uther]

Cherche pas a comprendre, tu perd ton temps, c'est un vieux troll qui s'amuse a écrire un peu partout des truc qui ont l'air techniques mais qui ne veulent rien dire.
D'habitude quand on ignore les trolls ils finissent par ce lasser, mais celui là est coriace.

[melka one]

certains se sent plus a l'aise avec while qu'avec for et vice versa c'est vraiment dommage de supprimer for

[MikeRowSoft]

Il n'y a que moi à n'avoir jamais vraiment compris ce que MikeRowSoft écrit ?

Sinon, je trouve dommage que la boucle for disparaisse complètement.
D'un certain point de vue, la boucle for en langage C est tout aussi "supprimable" car la boucle while fait très bien le job, mais bon ...
pour ceux qui connaisse swift mieux que moi, est-ce que for-in peut complément remplacer for ?

Je te rassure, tu n'es pas le seul à faire cette remarque.

Ton intérêt pour la boucle for est sûrement du coté pratique d'un axe de réflexion, c'est un coté humain sur les habitudes cognitives.
"Préférer faire comme ci au lieu de comme sa" si je ne fais pas de faute de sens (orthographe).
Les ambidextres par exemple n'ont pas forcément cette notion lors de la pratique de l'écriture.

Mon exemple était surement un peu trop en avance sur la gestion de sémaphore et des informations délivrés par des capteurs ou sondes, désolé, c'était du pas approprié pour se langage peut-être...
Les prochains CPU AMD ayant x86_64 et A.R.M. vous y pensez?

[tabouret]

Moi qui pensait les informaticiens feignants je viens de me tromper : pourquoi se faire chier à supprimer un élément du langage ? c'est de la perte de temps pour rien dans ce cas pourquoi ne pas supprimer le switch? c'est vrai le if else le fait très bien aussi.
Bref ridicule

[MikeRowSoft]

Cherche pas a comprendre, tu perd ton temps, c'est un vieux troll qui s'amuse a écrire un peu partout des truc qui ont l'air techniques mais qui ne veulent rien dire.
D'habitude quand on ignore les trolls ils finissent par ce lasser, mais celui là est coriace.

T'a jamais eu affaire à des bêtas testeurs c'est peut-être sa le problème, à moins que tu le sois. J'espère que j'aurais jamais à me plaindre de tes produits ou méthodes bien que j'en doute fort.

[jopopmk]

On va peut-être pas trop s'attarder sur le jugement des contributions de MikeRowSoft, nop ?
(même si moi non plus je comprends pas toujours )

Pour revenir au sujet, en lisant le premier paragraphe après les exemples, on a un peu l'impression qu'un gars a dit à la team Swift : "la boucle for façon C j'm'en sers pas et au pire on peut bidouiller pour avoir le même fonctionnement autrement, alors virez là" ... ça sonne quand même un peu étrange.

Maintenant, le Swift je suis ça de loin, je ne compte pas particulièrement développer avec à l'avenir.

[23JFK]

Du même niveau que d'aller remplacer les while(){} , do{} while(); for( ; ; ) , switch(){case:} et else par l'unique combinaison de if() goto label. For-in n'est pas capable de gérer des formules d'incrémentation complexes ni des conditions d'arrêt complexes ni des assignements multiples, de plus for-in est dans tous les cas plus lent qu'un for( ; ; ). Une vraie bonne grosse idée à la con qui va disqualifier swift pour les gros projets si elle est mise en oeuvre.

[Uther]

Moi qui pensait les informaticiens feignants je viens de me tromper : pourquoi se faire chier à supprimer un élément du langage ? c'est de la perte de temps pour rien dans ce cas pourquoi ne pas supprimer le switch? c'est vrai le if else le fait très bien aussi.
Bref ridicule

Le switch en Swift fait du pattern matching ce qui permet de faire des chose bien plus évoluées qu'une simple suite de if.

for-in est dans tous les cas plus lent qu'un for( ; ; ).

Non. A moins que l'optimisateur soit mauvais, les for each sont normalement aussi rapides de les for classique, voire plus quand il permettent d'économiser un contrôle de dépassement.

[NSKis]

Il est parfois nécessaire d'admirer dans toute son ampleur "l'intelligence" humaine...

On résume:

1° Les gars ont l'idée de supprimer le "For" (Pourquoi? Bof! On savait pas quoi proposer!!!)

2° Les gars listent tous les problèmes que cela va poser à plein de monde

3° Les gars proposent de supprimer le "For" malgré tout (ben oui quoi, après une idée à la c..., une logique de c...!!!)


Un conseil pour tout ceux qui doivent maintenir un logiciel plusieurs années (parce que oui messieurs de Swift, dans le monde réel, on ne redéveloppe pas une application à chaque poussée de chaleur des concepteurs du langage utilisé): Fuyez!!! Lorsque l'évolution d'un langage n'est pas capable d'assurer la perennité de sa propre syntaxe, il ne s'agit pas d'un langage "professionnel"

[Jhulk]

Je trouve d'une stupidité applesque !

Non seulement pour les cas simples on nous dit que c'est moins performant, mais en plus les raisons évoquées ne justifient vraiment pas une telle régression, les mecs bossent quand même à enlever des possiblités de développement.

Les devs feront quand même des for avec des while dont la condition de sortie sera testée dans la boucle.

J'espère sincèrement que ce mouvement ne sera pas suivi par les autres langages ...

[Ukualai]

Franchement, c'est le genre de chose à ne absolument pas faire et ne présage rien de bon pour la maintenabilité des applications qui seront codé en swift.
Encore une fois Apple montre bien que rien ne perdure même en open source...

[Kiloastein]

Je trouve pas important de faire disparaitre une boucle juste parce qu'il ya une "meilleure". Je fais partie de ceux qui sont á l'aise avec la boucle for ... ce serait vraiment domage de nous en priver.

[Kiloastein]

C'est pas gentil de vouloir faire. Et pourquoi faudrait la faire disparaitre? While existe toujours pas vrai?? Elle est pas tellement différente de For. C'est bien d'en créer de nouvelles mais c'est pas une raison suffisante pour effacer une autre.

[Uther]

Pour moi l'idée de faire disparaitre le for n'est pas mauvaise en soi : la syntaxe C est globalement dispensable. La plupart des gens l'utilisent simplement par habitude alors qu'ils feraient certainement mieux en lisibilité (et parfois en performance) avec un "for ... in". Pour les rares fois ou il ne convient pas, c'est facile de le remplacer par un while.

C'est le choix qu'a fait Rust et ça fonctionne très bien. Mais la grosse différence avec Swift, c'est que Rust a fait ce choix avant sa première version stable. Introduire ce genre de changement qui va complètement casser la compatibilité ascendante alors que Swift est sorti de manière officielle depuis plus d'un an, c'est inquiétant pour la stabilité du langage.

[CodeurPlusPlus]

Du même niveau que d'aller remplacer les while(){} , do{} while(); for( ; ; ) , switch(){case:} et else par l'unique combinaison de if() goto label. For-in n'est pas capable de gérer des formules d'incrémentation complexes ni des conditions d'arrêt complexes ni des assignements multiples, de plus for-in est dans tous les cas plus lent qu'un for( ; ; ). Une vraie bonne grosse idée à la con qui va disqualifier swift pour les gros projets si elle est mise en oeuvre.

Tout à fait. Il va falloir qu'on m'explique un jour d'où vient cette maladie des langages dits "modernes" qui consiste à ne pas assurer une rétro-compatibilité avec eux-mêmes. On avait un "for" jusque-là, mais on va le virer, préparez-vous à réécrire votre code pour vous adapter à nos changements d'humeur !

Le "for-each" (où je ne sais quel autre néologisme) est mieux ? Très bien, utilitons-en ! Mais gardons le "for" classique au moins pour la compatibilité ascendante.

Personnellement je boycotte les logiciels qui ne sont pas rétro-compatibles avec eux-mêmes, donc je suppose que je ne programmerai jamais en Swift.