Discussion :

[Bill Fassinou]

Feuille de route de Rust pour 2021 : l'équipe souhaite étendre la communauté du langage
et pourrait travailler sur une éventuelle édition de Rust 2021

L’année 2020 est en train de prendre fin et les objectifs de l’année 2021 se dressent peu à peu déjà dans les différentes organisations. L’équipe principale de Rust a publié cette semaine une idée de sa feuille de route pour 2021 et désire entendre le retour de la communauté avant de sortir une feuille de route officielle. L’un des principaux objectifs qu’elle vise est de continuer à étendre la communauté du langage. L’équipe compte lancer dans la semaine prochaine une étude sur l’état de Rust en 2020 et un appel à la publication d'articles sur les différents blogues de Rust.

Dans un premier temps, l’équipe a déclaré que les articles de blogue sont essentiels afin d’assurer l’extension de la communauté de Rust. Ils peuvent contenir tout ce qui a trait au langage, dont les caractéristiques linguistiques, les améliorations des outils, les besoins de l'écosystème, les changements organisationnels. Ainsi, elle encourage les uns et les autres à essayer d'identifier les thèmes ou les grands domaines dans lesquels vos suggestions s'inscrivent, car celles-ci permettront d’orienter l'ensemble du projet. Elle vous invite également à donner votre vision de Rust.

« Une façon de nous aider à comprendre l'optique dans laquelle vous envisagez Rust est de donner une (ou plusieurs) déclaration de la forme : “En tant que X, je veux que Rust soit Y parce que Z” », a-t-elle déclaré. En voici un exemple : « En tant que développeur de systèmes embarqués qui souhaite développer sa niche, je veux que Rust facilite le développement embarqué de bout en bout afin que les nouveaux venus puissent se lancer plus facilement ». En marge de cela, l’équipe s’est dite fière de ce qu’elle a pu accomplir cette année et annonce sa prévision pour 2021.

Préparez-vous à une éventuelle édition de Rust 2021

Selon l’équipe, il existe maintenant un RFC ouvert proposant un plan pour l'édition 2021. Elle a déclaré qu’il y a eu pas mal de discussions, mais qu’elle espère les fusionner dans les 6 prochaines semaines. Il est prévu que la nouvelle édition ait une portée beaucoup plus limitée que celle de Rust 2018. Elle devrait inclure quelques ajustements mineurs pour améliorer la convivialité du langage et la promotion de différents idiomes d'édition afin qu'ils soient “refusés par défaut”. Elle a espoir que cette édition sera aussi couronnée de succès.

Suivi des projets et des efforts en cours

L’équipe a déclaré que l'un des principaux objectifs de 2020 était de faire avancer les efforts de conception “en cours” jusqu'à leur achèvement, ajoutant qu’elle a vu beaucoup d'efforts aller dans ce sens, notamment.

• la référence au code assembleur en ligne a fusionné et la nouvelle mise en œuvre est prête pour l'expérimentation ;
• les macros de procédure ont été stabilisées dans la plupart des positions à partir de Rust 1.45 ;
• il existe une proposition pour MVP de const génériques, qui doit en temps normal être livrée en 2020 ;
• le groupe des fondations async prévoit de publier prochainement un RFC sur le thème du stream ;
• le groupe de projet “unwind” du FFI comble un vide de longue date en matière de solidité, et le premier RFC a été fusionné ;
• le groupe de projet “safe transmute” a proposé un projet de RFC ;
• le groupe de travail sur les aspects est en train de parfaire Chalk, de préparer l'intégration de rustc et observe l'utilisation expérimentale de l'analyseur de Rust ;
• l’équipe est en train de passer à l'analyseur de Rust comme solution officielle de l'EDI Rust, avec un RFC fusionné qui établit le plan ;
• le système de niveaux de Rust est en cours de formalisation, avec des garanties et des attentes définies dans un RFC en cours ;
• le travail sur les performances des compilateurs continue, avec des gains de 10 à 30 % sur un grand nombre de critères de référence ;
• la lecture des tampons non initialisés a un RFC ouvert, ce qui résout un autre problème de longue date pour les E/S dans Rust ;
• une proposition du groupe de projet pour la SIMD portable en std a un RFC ouvert ;
• une proposition de groupe de projet sur l'ergonomie de la gestion des erreurs, axée sur l'API std::error, a un RFC ouvert ;
• les mises à jour des modules std::sync sont actuellement en phase de brainstorming ;
• le support de Rustdoc aux liens intra-doc est maintenant proche de la stabilisation.

Il y a eu beaucoup d'autres travaux aussi bien au sein des équipes Rust, mais ces éléments mettent en évidence certains des problèmes et des conceptions sur lesquels les équipes Rust travaillent activement. Il y a, entre autres, l’amélioration du fonctionnement et de la gouvernance des projets, ainsi que la documentation et l’amélioration des processus de gestion du projet. Ce dernier a trois sous-objectifs principaux, dont :

Améliorer la visibilité de l'état des initiatives et des efforts de conception

Les équipes Rust passent à l'utilisation de groupes de projet pour les travaux exploratoires, visant à créer des groupes de personnes dédiées qui peuvent explorer une zone, proposer un design, mais aussi de le mener à bien. L'équipe linguistique a donné le coup d'envoi avec des groupes de projet de transmutation sécurisée, de déroulement FFI et d'assemblage en ligne. Selon l’équipe principale, tous ces projets ont été d'énormes succès. D'autres équipes cherchent également à utiliser ce modèle.

Accroître le mentorat, le leadership et la largeur de bande passante organisationnelle

Selon l’équipe principale du langage, l'équipe linguistique a identifié un parcours pour les contributeurs vers l'adhésion à l'équipe, impliquant la participation et la direction des efforts du groupe de projet. Par ailleurs, le groupe de travail sur la gouvernance a formalisé les processus existants en RFC, tels que le RFC du groupe de projet, le RFC de la politique d'accès, et plus encore. D’un autre côté, l'équipe de la bibliothèque est pionnière dans l'effort de rédaction de chartes formelles pour les équipes, avec l'aide du groupe de travail sur la gouvernance.

Rendre les discussions sur la conception plus productives et moins épuisantes

Enfin, l’équipe principale de Rust a déclaré que l'effort principal a été fourni par les groupes de projet, qui ont jusqu'à présent été largement couronnés de succès. « Nous espérons en faire davantage à l'avenir », a-t-elle conclu.

Source : Rust

Et vous ?

Qu'en pensez-vous ?

Voir aussi

La feuille de route 2019 de Rust est disponible et place l'année sous le signe de la maturité

Qu'est-ce qu'il se passe, du côté de la rubrique Rust ? Ouverture officielle et présentation de la feuille de route

Le langage Rust est la meilleure chance offerte à l'industrie informatique pour la mise sur pied d'applications système sécurisées, d'après Microsoft

Rust 1.46.0 est disponible et s'accompagne de plusieurs nouveautés dans const fn, ainsi que de deux nouvelles API dans la bibliothèque standard

[Bill Fassinou]

L'équipe de développement de Rust présente son plan pour Rust 2021 qui correspond à la troisième édition du langage
avec une amélioration significative à la façon dont Rust se comporte en pratique

L'équipe de Rust a annoncé mardi qu'elle publiera en octobre Rust 2021. Les détails de son plan indiquent que Rust 2021 contient un certain nombre de petits changements qui devraient apporter une amélioration significative à la façon dont Rust se comporte en pratique. Lors de la première annonce en septembre 2020, l'équipe avait déclaré qu'il est prévu que la nouvelle édition ait une portée beaucoup plus limitée que celle de Rust 2018. Elle devrait inclure quelques ajustements mineurs pour améliorer la convivialité du langage et la promotion de différents idiomes d'édition afin qu'ils soient “refusés par défaut”.

Qu'est-ce qu'une édition et en quoi est-elle importante ?

Selon l'équipe principale du langage, la sortie de Rust 1.0 a établi la "stabilité sans stagnation" comme un livrable essentiel de Rust. Depuis la version 1.0, la règle pour Rust a été qu'une fois qu'une fonctionnalité a été publiée dans la version stable, l'équipe s'engage à supporter cette fonctionnalité pour toutes les futures versions. Cependant, il est parfois utile de pouvoir apporter de petites modifications qui ne sont pas rétrocompatibles. L'exemple le plus évident est l'introduction d'un nouveau mot-clé, qui invaliderait les variables portant le même nom. Voici une illustration, selon l'équipe.

La première version de Rust n'avait pas les mots-clés async et await. Le changement soudain de ces mots en mots-clés dans une version ultérieure aurait cassé du code comme let async= 1;. Ainsi, les éditions sont le mécanisme par lequel l'équipe résout ce problème. Lorsqu'elle souhaite publier une fonctionnalité qui serait autrement incompatible avec le passé, elle le fait dans le cadre d'une nouvelle édition de Rust. Les éditions sont opt-in, et donc les crates existants ne voient pas ces changements jusqu'à ce qu'ils migrent explicitement vers la nouvelle édition.

Cela signifie que même la dernière version de Rust ne traitera toujours pas async comme un mot-clé, à moins que l'édition 2018 ou ultérieure ne soit choisie. Ce choix est fait par le crate dans le cadre de son Cargo.toml. Les nouveaux crates créés par cargo new sont toujours configurés pour utiliser la dernière édition stable.

Éditions, changements, rétrocompatibilité et migration

Selon l'équipe, les éditions ne divisent pas l'écosystème. « La règle la plus importante pour les éditions est que les crates d'une édition peuvent interagir de manière transparente avec les crates compilés dans d'autres éditions », explique-t-elle. Cela garantirait que la décision de migrer vers une édition plus récente est une décision "privée" que le crate peut prendre sans affecter les autres. L'exigence d'interopérabilité des crates implique donc certaines limites sur les types de changements qu'elle peut faire dans une édition. En général, les changements qui se produisent dans une édition ont tendance à être "superficiels".

« Tout le code Rust, quelle que soit l'édition, est finalement compilé dans la même représentation interne au sein du compilateur », note-t-elle. En outre, elle ajoute que la migration des éditions est facile et largement automatisée. « Notre objectif est de faciliter la mise à niveau des caisses vers une nouvelle édition », a-t-elle déclaré. « Lorsque nous publions une nouvelle édition, nous fournissons également des outils pour automatiser la migration. Il apporte à votre code les modifications mineures nécessaires pour le rendre compatible avec la nouvelle édition », a ajouté l'équipe.

Par exemple, selon elle, lors de la migration vers Rust 2018, il modifie tout ce qui est nommé async pour utiliser la syntaxe d'identifiant brut équivalente : r#async. Elle estime néanmoins que les migrations automatisées ne sont pas nécessairement parfaites : il peut y avoir des cas particuliers où des modifications manuelles sont encore nécessaires. L'outil s'efforce d'éviter les changements sémantiques qui pourraient affecter la correction ou les performances du code. En plus de l'outillage, elle maintient également un guide de migration d'édition qui couvre les changements qui font partie d'une édition.

Ce guide décrit le changement et indique où les gens peuvent en apprendre davantage à son sujet. Il couvre également tous les cas particuliers ou les détails que les gens doivent connaître. Le guide sert à la fois d'aperçu de l'édition, mais aussi de référence pour le dépannage rapide si les gens rencontrent des problèmes avec l'outillage automatisé.

Quels sont les changements prévus pour Rust 2021 ?

L'équipe a déclaré qu'au cours des derniers mois, le groupe de travail Rust 2021 a examiné un certain nombre de propositions concernant les éléments à inclure dans la nouvelle édition. Elle présente désormais la liste finale des changements retenus pour cette édition. Chaque fonctionnalité devait répondre à deux critères pour faire partie de cette liste. Premièrement, elle devait être approuvée par la ou les équipes Rust concernées. Deuxièmement, leur mise en œuvre devait être suffisamment avancée pour que l'équipe principale ait la certitude qu'elles sont terminées à temps pour les jalons prévus.

Ajouts a prelude

Prelude de la bibliothèque standard est le module contenant tout ce qui est automatiquement importé dans chaque module. Il contient des éléments couramment utilisés tels que Option, Vec, drop et Clone. L'équipe a expliqué que le compilateur Rust donne la priorité aux éléments importés manuellement sur ceux du prelude, afin de s'assurer que les ajouts au prelude ne cassent pas le code existant. Prenez un exemple où vous avez un crate ou un module appelé example contenant un pub struct Option.

Dans ce cas, use example::*; fera en sorte que Option se réfère sans ambiguïté à celui de example ; et non à celui de la bibliothèque standard. Cependant, l'ajout d'un trait au prelude peut casser le code existant d'une manière subtile. Un appel à x.try_into() utilisant un trait MyTryInto peut devenir ambigu et ne pas compiler si TryInto de std est également importé, puisqu'il fournit une méthode avec le même nom.

C'est la raison pour laquelle l'équipe n'a pas encore ajouté TryInto au prelude, car beaucoup de code serait cassé de cette façon. Comme solution, Rust 2021 utilisera un nouveau prelude. Il est identique à l'actuel, à l'exception de trois nouveaux ajouts :

• std::convert::TryInto ;
• std::convert::TryFrom ;
• std::iter::FromIterator.

Résolveur de fonctionnalités par défaut de Cargo

Depuis la version 1.51.0 de Rust, Cargo prend en charge un nouveau résolveur de fonctionnalités qui peut être activé avec resolver= "2" dans Cargo.toml. À partir de Rust 2021, ce sera la valeur par défaut. En d'autres termes, écrire edition= "2021" dans Cargo.toml impliquera resolver= "2". Le nouveau résolveur de fonctionnalités ne fusionne plus toutes les fonctionnalités demandées pour les crates qui sont dépendants de plusieurs façons.

IntoIterator pour les tableaux

Jusqu'à Rust 1.53, seules les références aux tableaux implémentent IntoIterator. Cela signifie que vous pouvez itérer sur &[1, 2, 3] et &mut [1, 2, 3], mais pas sur [1, 2, 3] directement. Selon l'équipe, il s'agit d'un problème de longue date, mais la solution n'est pas aussi simple qu'il paraît. L'ajout de l'implémentation du trait casserait le code existant. array.into_iter() compile déjà aujourd'hui parce qu'il appelle implicitement (&array).into_iter() en raison du fonctionnement de la syntaxe d'appel de méthode.

L'ajout de l'implémentation du trait en changerait la signification. Habituellement, l'équipe qualifie ce type de rupture de "mineure" et acceptable. Mais dans ce cas, il y a trop de code qui serait cassé par cela. Selon elle, il a été suggéré à plusieurs reprises de n'implémenter IntoIterator que pour les tableaux en Rust 2021. Cependant, cela n'est tout simplement pas possible. Vous ne pouvez pas avoir une implémentation de trait existant dans une édition et pas dans une autre, puisque les éditions peuvent être mélangées.

Au lieu de cela, l'équipe a décidé d'ajouter l'implémentation de trait dans toutes les éditions (à partir de Rust 1.53.0), mais d'ajouter un petit hack pour éviter la rupture jusqu'à Rust 2021. Dans le code Rust 2015 et 2018, le compilateur résoudra toujours array.into_iter() en (&array).into_iter() comme avant, comme si l'implémentation du trait n'existait pas. Cela s'applique uniquement à la syntaxe d'appel de la méthode .into_iter(). Cela n'affecte pas les autres syntaxes telles que for e in [1, 2, 3], iter.zip([1, 2, 3]) ou IntoIterator::into_iter([1, 2, 3]).

Celles-ci commenceront à fonctionner dans toutes les éditions. Selon l'équipe, bien qu'il soit dommage que cela nécessite un petit hack pour éviter la casse, elle se dit heureuse de la façon dont cette solution maintient la différence entre les éditions à un minimum absolu. Comme le hack n'est présent que dans les anciennes éditions, il n'y a pas de complexité supplémentaire dans la nouvelle édition.

Capture disjointe dans les closures

Les closures capturent automatiquement tout ce à quoi vous faites référence à l'intérieur de leur corps. Par exemple, || a + 1 capture automatiquement une référence à a à partir du contexte environnant. Actuellement, cela s'applique à des structures entières, même si elles n'utilisent qu'un seul champ. Par exemple, || a.x + 1 capture une référence à a et pas seulement à a.x. Selon l'équipe, dans certaines situations, cela pose un problème. Lorsqu'un champ de la structure est déjà emprunté ou déplacé, les autres champs ne peuvent plus être utilisés dans une fermeture,

Cela aura pour effet de capturer la structure entière, qui n'est plus disponible. À partir de Rust 2021, les fermetures ne captureront que les champs qu'elles utilisent. Ainsi, l'exemple ci-dessus compilera bien en Rust 2021. Ce nouveau comportement n'est activé que dans la nouvelle édition, car il peut changer l'ordre dans lequel les champs sont supprimés. Comme pour tous les changements d'édition, une migration automatique est disponible, qui mettra à jour vos closures pour lesquelles cela est important. Il peut insérer let _ = &a; à l'intérieur de la closure pour forcer la capture de la structure entière comme avant.

Cohérence de la macro panic

La macro panic!() est l'une des macros les plus connues de Rust. Cependant, l'équipe estime qu'elle présente quelques surprises subtiles qu'elle ne peut pas modifier pour des raisons de compatibilité ascendante. La macro panic!() n'utilise le formatage des chaînes que lorsqu'elle est invoquée avec plus d'un argument. Lorsqu'elle est invoquée avec un seul argument, elle ne regarde même pas cet argument. (Elle accepte même les non-chaînes de caractères comme panic!(123), ce qui est peu courant et rarement utile). Ceci serait particulièrement un problème une fois que les arguments de format implicites seront stabilisés.

Cette fonctionnalité fera de println!("hello {name}") un raccourci pour println!("hello {}", name). Cependant, panic!("hello {name}") ne fonctionnerait pas comme prévu, puisque panic!() ne traite pas un argument unique comme chaîne de format. Pour éviter cette situation confuse, Rust 2021 propose une macro panic!() plus cohérente. La nouvelle macro panic!() n'acceptera plus les expressions arbitraires comme seul argument. Tout comme println!(), elle traitera toujours le premier argument comme une chaîne de format.

Puisque panic!() n'acceptera plus de charges utiles arbitraires, panic_any() sera le seul moyen d'utiliser panic!() avec autre chose qu'une chaîne formatée. De plus, core::panic!() et std::panic!() seront identiques dans Rust 2021. Actuellement, il y a quelques différences historiques entre ces deux-là, qui peuvent être perceptibles lors de l'activation ou de la désactivation de #![no_std].

Réserver la syntaxe

Pour faire de la place pour une nouvelle syntaxe dans le futur, l'équipe a décidé de réserver la syntaxe pour les identificateurs et les littéraux préfixés : prefix#identifier, prefix "string", prefix "c", et prefix#123, où prefix peut être n'importe quel identificateur. (Sauf ceux qui ont déjà une signification, comme b'...' et r"..."). Il s'agit d'un changement de rupture, puisque les macros peuvent actuellement accepter hello"world", qu'elles verront comme deux jetons séparés : hello et "world".

La correction (automatique) est cependant simple. Il suffit d'insérer un espace : hello "world". En dehors de la transformation de ces erreurs en erreurs de tokénisation, la RFC n'attache pas encore de signification à un quelconque préfixe. L'attribution d'une signification à des préfixes spécifiques est laissée aux propositions futures, qui, grâce à la réservation de ces préfixes maintenant, ne seront pas des changements de rupture. Voici quelques nouveaux préfixes que vous pourriez voir à l'avenir :

• f"" comme raccourci pour une chaîne de format. Par exemple, f"hello {name}" comme raccourci de l'invocation format_args!() équivalente ;
• c"" ou z"" pour les chaînes C à terminaison nulle ;
• k#keyword pour permettre l'écriture de mots-clés qui n'existent pas encore dans l'édition actuelle. Par exemple, bien que async ne soit pas un mot-clé dans l'édition 2015, ce préfixe aurait permis d'accepter k#async comme alternative dans l'édition 2015 en attendant que l'édition 2018 réserve async comme mot-clé.

Promotion de deux avertissements en erreurs graves

Deux lints existantes deviennent des hard errors dans Rust 2021. Ces lints resteront des avertissements dans les anciennes éditions.

• bare-trait-objects : l'utilisation du mot-clé dyn pour identifier les objets traits sera obligatoire dans Rust 2021 ;
• ellipsis-inclusive-range-patterns : la syntaxe dépréciée ... pour les modèles de plage inclusive n'est plus acceptée dans Rust 2021. Elle a été remplacée par ..=, qui est cohérente avec les expressions.

Les motifs dans macro_rules

À partir de Rust 1.53.0, les motifs sont étendus pour supporter les | imbriqués n'importe où dans le motif. Cela vous permet d'écrire Some(1 | 2) au lieu de Some(1) | Some(2). Comme cela n'était tout simplement pas autorisé auparavant, il ne s'agit pas d'un changement radical. Toutefois, ce changement affecte également les macros macro_rules. Ces macros peuvent accepter des motifs utilisant le spécificateur de fragment :pat. Actuellement, :pat ne correspond pas à |, car avant Rust 1.53, tous les motifs (à tous les niveaux imbriqués) ne pouvaient pas contenir un |.

Les macros qui acceptent des motifs comme A | B, comme matches!() utilisent quelque chose comme $($_:pat)|+. L'équipe a déclaré que, comme elle ne veut pas casser les macros existantes, elle n’a pas modifié la signification de :pat dans Rust 1.53.0 pour inclure |. Au lieu de cela, elle fera ce changement dans le cadre de Rust 2021.

Dans la nouvelle édition, le spécificateur de fragment :pat correspondra à A | B. Comme il arrive parfois que l'on souhaite faire correspondre une seule variante de motif sans |, le fragment spécifié :pat_param a été ajouté pour conserver l'ancien comportement. Le nom fait référence à son principal cas d'utilisation : un motif dans un paramètre closure.

Quelles sont les prochaines étapes ?

L'équipe prévoit de fusionner ces changements et de les tester entièrement d'ici septembre, afin de s'assurer que l'édition 2021 sera intégrée à Rust 1.56.0. Rust 1.56.0 sera alors en version bêta pendant six semaines, après quoi il sera publié en version stable le 21 octobre. Cependant, notez que Rust est un projet géré par des bénévoles, il peut donc arriver que le calendrier soit bouleversé.

« Nous donnons la priorité au bien-être personnel de tous ceux qui travaillent sur Rust plutôt qu'aux délais et aux attentes que nous avons pu fixer. Cela peut signifier retarder l'édition d'une version si nécessaire, ou abandonner une fonctionnalité qui s'avère trop difficile ou trop stressante pour être terminée à temps. Cela dit, nous sommes dans les temps et beaucoup de problèmes difficiles sont déjà résolus, grâce à toutes les personnes qui contribuent à Rust 2021 », a-t-elle déclaré.

Source : Plan de l'édition Rust 2021

Et vous ?

Que pensez-vous des changements intervenus dans Rust 2021 ?

Voir aussi

Feuille de route de Rust pour 2021 : l'équipe souhaite étendre la communauté du langage et pourrait travailler sur une éventuelle édition de Rust 2021

Rust 1.51 est disponible avec Resolver, une nouvelle fonctionnalité pour Cargo et l'implémentation MVP des const generics

Rust 1.50.0 est disponible et s'accompagne de l'indexation de tableau générique Const, ainsi que des affectations sécurisées aux champs d'union ManuallyDrop<T>

Rust 1.49.0 est disponible avec l'amélioration des supports de Linux ARM 64 bits, MacOS et Windows ARM 64 bits

[Bill Fassinou]

L'édition Rust 2021 et la version stable Rust 1.56 sont maintenant disponibles en téléchargement
la nouvelle édition du langage inclut la prise en charge des captures disjointes

L'équipe Rust a publié la version 1.56 du langage de programmation dans les délais prévus, ce qui marque également le début de la nouvelle édition Rust 2021. Les innovations les plus importantes comprennent une capture modifiée des variables dans les closures et une itération propre sous le capot sur les valeurs des tableaux au lieu des références. L'équipe a laissé entendre que l'édition 2021 du langage est petite, mais inclut quelques changements de qualité de vie.

Une édition au lieu de la version principale

La version portant le numéro discret 1.56 marque le début de la troisième édition du langage de programmation après Rust 2015 et 2018, qui a été annoncée pour la première fois en mai. Les nouvelles éditions introduisent des fonctionnalités supplémentaires qui peuvent entraîner des incompatibilités avec les éditions précédentes. Toutefois, la mise à jour devrait apporter le moins de changements de rupture possible. Les éditions ne divisent pas l'écosystème. « La règle la plus importante pour les éditions est que les crates d'une édition peuvent interagir de manière transparente avec les crates compilées dans d'autres éditions », explique l'équipe.




Rust avait embarqué le pattern [C=Rust]async await[/Rust] en 2018, ce qui, par effet de bord, incluait les nouveaux mots-clés [C=Rust]async[/Rust] et [C=Rust]await[/Rust]. Cela pouvait devenir un problème si le code utilisait les termes précédemment sans réserve comme noms de variables, par exemple, ce qui est rarement le cas. Comme les changements d'une édition à l'autre sont généralement plutôt modérés, l'équipe Rust s'est prononcée contre le passage à une nouvelle version principale lors du premier saut d'édition en 2018. Ainsi, Rust 1.56 et Rust 2021 sont une seule et même version.

Les développeurs déterminent l'édition respective pour chaque crate. Par conséquent, il n'est pas nécessaire de modifier l'ancien code pour l'utiliser avec le code source de la dernière édition. Enfin, sous le capot, le compilateur crée une représentation interne uniforme pour le code mixte. « L'édition 2021 de Rust est petite, mais représente une évolution significative du langage », a déclaré Armin Ronacher, directeur de l'ingénierie chez Sentry et développeur Rust de longue date.

« Bien qu'en surface, elle semble sans conséquence, elle montre que Rust reste fidèle à sa détermination de rétrocompatibilité et évolue à un rythme régulier vers un langage de programmation système plus puissant ». Rust 2021 a apporté des améliorations aux conversions de types faillibles, a résolu quelques défauts (comme l'incapacité d'itérer sur des tableaux), a ajouté un nouveau résolveur de dépendances plus puissant, et des règles de capture de closure plus flexibles.

Les changements intervenus dans Rust 2021

Capture disjointe dans les closures

Un grand changement dans Rust 2021 concerne les closures, un concept de fonctions anonymes dans Rust qui fonctionne de manière similaire aux expressions lambda dans Kotlin, Java et C# ou aux fonctions fléchées dans JavaScript. Les closures capturent automatiquement tout ce à quoi vous faites référence à l'intérieur de leur corps. Par exemple, || a + 1 capture automatiquement une référence à a à partir du contexte environnant. Avant le traitement, les closures obtiennent du contexte une référence aux objets utilisés. La liaison des variables est appelée capturing.

À partir de Rust 2021, elles ne reçoivent que les sous-objets réellement utilisés, par exemple dans la construction || a.x + 1, uniquement le champ demandé a.x , au lieu de la structure complète a à lier. Cela signifie que l'accès est toujours possible même si un autre champ a été accédé précédemment, par exemple via drop(a.y) a été supprimé. Jusqu'à présent, cela a conduit à une erreur parce que Rust n'a plus la structure a complète à référencer, mais ce n'est pas nécessaire pour la closure dans ce cas. Voici un autre exemple :

Code Rust :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// 2015 or 2018 edition code
let a = SomeStruct::new();
 
// Move out of one field of the struct
drop(a.x);
 
// Ok: Still use another field of the struct
println!("{}", a.y);
 
// Error: Before 2021 edition, tries to capture all of `a`
let c = || println!("{}", a.y);
c();

Pour résoudre ce problème, vous auriez dû extraire quelque chose comme let y = &a.y; manuellement avant la closure pour limiter sa capture. À partir de Rust 2021, les fermetures ne captureront automatiquement que les champs qu'elles utilisent, donc l'exemple ci-dessus compilera bien.

La nouvelle procédure ne s'applique que si les développeurs activent l'édition 2021, car elle peut casser le code existant dans certains cas. Cela pourrait potentiellement changer l'ordre dans lequel les champs sont supprimés (drop)will. L'underscore peut être utilisé pour forcer l'ancien comportement dans la nouvelle édition et pour lier la structure entière : let _ = &a;.

Une valeur au lieu d'une référence

Une autre innovation s'est progressivement introduite dans Rust par rapport aux versions précédentes : l'itération sur des tableaux par valeur avec son propre trait. Rust 1.51 avait initialement introduit l'API std::array::IntoIter. Depuis la version 1.53, les tableaux implémentent le trait IntoIterator, qui permet d'itérer directement sur des tableaux par valeur sous la forme suivante :

Code Rust :

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

1
2
3
4
 
for i in [1, 2, 3] {
    ..
}

En effet, jusqu'à Rust 1.53, seules les références aux tableaux implémentent IntoIterator. Cela signifie que vous pouvez itérer sur &[1, 2, 3] et &mut [1, 2, 3], mais pas sur [1, 2, 3] directement. Selon l'équipe, il s'agit d'un problème de longue date, mais la solution n'est pas aussi simple qu'il paraît. L'ajout de l'implémentation du trait casserait le code existant. array.into_iter() compile déjà aujourd'hui parce qu'il appelle implicitement (&array).into_iter() en raison du fonctionnement de la syntaxe d'appel de méthode.

Lors de l'annonce de Rust 2021 en mai, elle a déclaré que l'ajout de l'implémentation du trait en changerait la signification. Habituellement, l'équipe qualifie ce type de rupture de "mineure" et acceptable. Mais dans ce cas, il y a trop de code qui serait cassé par cela. Selon elle, il a été suggéré à plusieurs reprises de n'implémenter IntoIterator que pour les tableaux en Rust 2021. Cependant, cela n'est tout simplement pas possible. Vous ne pouvez pas avoir une implémentation de trait existant dans une édition et pas dans une autre, puisque les éditions peuvent être mélangées.

Au lieu de cela, l'équipe a décidé d'ajouter l'implémentation de trait dans toutes les éditions (à partir de Rust 1.53), mais d'ajouter un petit hack pour éviter la rupture jusqu'à Rust 2021. Dans le code Rust 2015 et 2018, le compilateur résoudra toujours array.into_iter() en (&array).into_iter() comme avant, comme si l'implémentation du trait n'existait pas. Cela s'applique uniquement à la syntaxe d'appel de la méthode .into_iter(). Cela n'affecte pas les autres syntaxes telles que for e in [1, 2, 3], iter.zip([1, 2, 3]) ou IntoIterator::into_iter([1, 2, 3]).

Celles-ci commenceront à fonctionner dans toutes les éditions. Selon l'équipe, bien qu'il soit dommage que cela nécessite un petit hack pour éviter la casse, elle se dit heureuse de la façon dont cette solution maintient la différence entre les éditions à un minimum absolu. Comme le hack n'est présent que dans les anciennes éditions, il n'y a pas de complexité supplémentaire dans la nouvelle édition.

Les autres changements dans Rust 2021

• les motifs des macro-règles correspondent au niveau supérieur A|B ;
• la version 2 du résolveur de fonctionnalités Cargo est maintenant par défaut ;
• TryInto, TryFrom et FromIterator sont maintenant dans la portée par défaut ;
• les macros de panique attendent désormais des chaînes de format ;
• la syntaxe est réservée à ident#, ident"..." et ident'...' ;
• le code qui déclenche bare_trait_objects et ellipsis_inclusive_range_patterns donne désormais une erreur.

Les API stabilisées dans Rust 2021

Les méthodes et implémentations de traits suivantes ont été stabilisées :

• std::os::unix::fs::chroot ;
• UnsafeCell::raw_get ;
• BufWriter::into_parts ;
• core::panic::{UnwindSafe, RefUnwindSafe, AssertUnwindSafe} ;
• (auparavant uniquement dans std) ;
• Vec::shrink_to ;
• String::shrink_to ;
• OsString::shrink_to ;
• PathBuf::shrink_to ;
• BinaryHeap::shrink_to ;
• VecDeque::shrink_to ;
• HashMap::shrink_to ;
• HashSet::shrink_to.

Les fonctions suivantes, auparavant stables, sont maintenant constantes :

• std::mem::transmute ;
• [T]::first ;
• [T]::split_first ;
• [T]::last ;
• [T]::split_last.

Source : Rust 1.56 et Rust 2021

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'édition 2021 de Rust ?
Rust est-il en bonne voie pour remplacer le langage C en tant que langage de programmation système ?

Voir aussi

Feuille de route de Rust pour 2021 : l'équipe souhaite étendre la communauté du langage et pourrait travailler sur une éventuelle édition de Rust 2021

L'équipe de développement de Rust présente son plan pour Rust 2021 qui correspond à la troisième édition du langage, avec une amélioration significative à la façon dont Rust se comporte en pratique

Rust 1.51 est disponible avec Resolver, une nouvelle fonctionnalité pour Cargo et l'implémentation MVP des const generics

Rust 1.50.0 est disponible et s'accompagne de l'indexation de tableau générique Const, ainsi que des affectations sécurisées aux champs d'union ManuallyDrop<T>