Je présente à votre attention une traduction de la publication sur la nouvelle version du langage de programmation préféré de tout le monde, Rust .
Présentation
L'équipe du langage de programmation Rust est heureuse d'annoncer une nouvelle version, 1.36.0. Rust est un langage de programmation qui permet à chacun de développer des logiciels fiables et rapides.
Si vous avez installé la version précédente de Rust à l'aide de rustup , obtenir la version actuelle ne sera pas difficile:
$ rustup update stable
Si vous n'avez toujours pas de rustup , vous pouvez l' obtenir à partir de la page correspondante sur notre site Web. Une revue détaillée de cette version est disponible sur GitHub.
Qu'est-ce qui est inclus dans la version stable?
Cette version a apporté de nombreux changements, notamment la stabilisation du trait Future tant attendu, l' MaybeUninit<T> alloc , la MaybeUninit<T> , NLL Rust 2015 , une nouvelle implémentation de HashMap<K, V> et la prise en charge du drapeau --offline dans Cargo.
Les changements les plus importants sont décrits ci-dessous, mais vous pouvez également voir une liste détaillée des innovations pour une sensibilisation supplémentaire.
Stabilisation future
La rouille 1.36.0 a stabilisé le Future tant attendu!
Nous espérons que cette innovation permettra aux caisses populaires, aux bibliothèques et à l'ensemble de l'écosystème de se préparer à la .await async / .await , qui devrait être stabilisée dans un avenir proche.
Stabilisation du rack de distribution
Avant la version 1.36.0, la bibliothèque standard était constituée de proc_macro std , core et proc_macro . La core avait des fonctionnalités de base (comme Iterator et Copy ) et pouvait être utilisée dans des environnements avec #![no_std] , car elle n'imposait aucune exigence. Pendant ce temps, la caisse std fourni des types tels que Box<T> , ainsi que la fonctionnalité du système d'exploitation (allocateur global).
Depuis Rust 1.36.0, les composants de la caisse standard, qui dépendent de l'allocateur global, par exemple, Vec<T> , sont désormais disponibles dans la alloc allocation. La std , quant à elle, réexporte ces composants.
Alors que les programmes #![no_std] utilisant la caisse d' #![no_std] nécessitent toujours le canal nightly , les #![no_std] c #![no_std] peuvent utiliser la alloc dans Rust stable.
Nous notons également que tous les programmes "réguliers" (sans #![no_std] ) dans leurs dépendances sont capables de contenir les bibliothèques décrites ci-dessus avec #![no_std] . Nous espérons que cela aidera à développer un écosystème compatible avec #![no_std] .
Si vous êtes un développeur d'une bibliothèque qui nécessite des primitives d'allocation pour fonctionner, nous vous recommandons de marquer votre bibliothèque comme compatible avec #![no_std] utilisant la syntaxe suivante au début du fichier lib.rs :
#![no_std] extern crate alloc; use alloc::vec::Vec;
Peut-être Uninit place mem :: uninitialized
Dans les versions précédentes de Rust, la fonction mem::uninitialized vous permettait d'annuler les vérifications d'initialisation car elle pensait que vous DÉJÀ initialisé au type T sans rien faire. L'une des utilisations de cette fonction était l'allocation "paresseuse" des tableaux.
Cependant, mem::uninitalized est une opération trop dangereuse qui ne peut pas être utilisée correctement avec le compilateur Rust, en supposant que toutes les valeurs sont correctement initialisées.
Par exemple, appeler mem::uninitialized::<bool>() provoquera immédiatement un comportement indéfini , car du point de vue de Rust, les bits non initialisés sont soit zéro ( false ) ou unité ( true ), et seuls deux des modèles ci-dessus conviennent au type bool .
Pour résoudre cette situation, le type MaybeUninit<T> été stabilisé dans Rust 1.36.0. Le compilateur Rust ne suppose plus que MaybeUninit<T> est un type de T initialisé Ainsi, vous pouvez effectuer une initialisation progressive plus en toute sécurité et enfin utiliser .assume_init() lorsque vous êtes sûr que maybe_t: MaybeUninit<T> - maybe_t: MaybeUninit<T> contient le type T initialisé
Étant donné que MaybeUninit<T> est une alternative plus sûre à partir de Rust 1.38, la fonction mem::uninitialized sera marquée comme obsolète.
Pour en savoir plus sur la mémoire non initialisée, mem::uninitialized et MaybeUninit<T> , lisez l' article d'Alexis Bessessner . La bibliothèque standard contient également une documentation suffisante sur MaybeUninit<T> .
NLL pour Rust 2015
Dans l'annonce de Rust 1.31.0, nous vous avons parlé de NLL (chronologies de vie non lexicales), une innovation dans le langage qui rend le contrôleur de lien (vérificateur d'emprunt) plus intelligent et plus convivial. Par exemple, vous pouvez maintenant écrire comme ceci:
fn main() { let mut x = 5; let y = &x; let z = &mut x;
À 1,31,0, le NLL a été stabilisé uniquement pour Rust 2018, et il a été supposé que nous le transférerions à Rust 2015 à l'avenir. Cela a été fait dans Rust 1.36.0, NLL est devenu disponible pour Rust 2015.
Avec NLL pris en charge dans les deux versions, nous approchons de la suppression de l'ancien contrôleur de liaison. Cependant, l'ancien contrôleur de liaison a malheureusement accepté un code incorrect , qu'il n'aurait PAS dû accepter.
Et, par conséquent, NLL est maintenant à l'étape de «migration», dans laquelle nous émettrons des avertissements au lieu d'erreurs si le contrôleur de liaison NLL n'approuve pas le code qui approuverait l'ancien contrôleur de liaison basé sur AST . Nous vous conseillons de consulter la liste des caisses publiques concernées .
Pour en savoir plus sur NLL, MIR, comment résoudre les problèmes d'intégrité associés et ce qui peut être fait avec les avertissements du compilateur qui apparaissent, lisez l'article de Felix Klok .
Nouvelle implémentation de HashMap
Dans Rust 1.36.0, l'implémentation précédente de HashMap<K, V> été remplacée par une hashbrown hashbrown basée sur la conception de SwissTable . L'interface reste la même, mais l'implémentation actuelle est en moyenne plus rapide et consomme moins de mémoire. Cependant, notez que l'implémentation standard utilise toujours l'algorithme SipHash 1-3 .
- Support hors ligne dans Cargo
Pendant la plupart des versions, Cargo n'utilise pas votre réseau. Cependant, à certains moments, par exemple, lorsqu'une nouvelle dépendance a été ajoutée, Cargo essaiera toujours d'accéder au réseau. Parfois, ce comportement est inacceptable (dans un système isolé ou dans un avion).
La rouille 1.36.0 a stabilisé le nouveau drapeau - --offline . Cet indicateur remplace l'algorithme de résolution de dépendance, à la place en utilisant des dépendances mises en cache locales.
Si les caisses demandées ne sont pas disponibles sans un réseau qui a été déconnecté, Cargo se fermera avec une erreur. Pour préremplir le cache local avant de quitter le réseau, utilisez la commande cargo fetch , qui charge toutes les dépendances nécessaires pour un projet spécifique.
Pour en savoir plus sur --offline et cargo fetch , lisez l'article de Nick Cameron . D'autres modifications apportées à Cargo sont décrites en détail ici .
Modifications de la bibliothèque
Macro dbg! a commencé à soutenir plusieurs arguments;
Certaines méthodes sont devenues constantes:
Certaines API sont stabilisées, notamment:
Autres changements
Des descriptions détaillées des modifications dans la version 1.36.0 sont disponibles pour Rust , la bibliothèque standard , Cargo et Clippy .
Membres 1.36.0
Beaucoup de gens se sont réunis pour créer Rust 1.36.0. Nous n'aurions pas pu faire cela sans vous tous, merci !
Du traducteur
Pour toute question sur la langue rouille, ils pourront vous aider dans le chat Telegram en russe ou dans un chat similaire pour les nouveaux arrivants .