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[...