Journal L'édition 2018 de Rust est sortie !

Sommaire

• Édition ? Jamais entendu parler de ça
  • Qu'est-ce qu'une édition en Rust ?
  • Quid de la stabilité ?
  • Comment utiliser cette édition ?
• Quelles sont les nouveautés ?
  • Le système de modules
    • Les chemins
    • Les dépendances externes
    • Les macros
    • Quel fichier pour quel module
    • De nouveaux types de modifieurs de visibilité
    • Directive use imbriquée
  • Système de trait
  • Simplification concernant les types lifetime
    • Lifetimes non lexicaux
    • Pattern matching plus intelligent
    • Simplification dans l'écriture des lifetimes génériques
  • Autres
    • Notations pour le code asynchrone
    • SIMD, 128 bits
    • Macros procédurales
    • Zero ou une occurence dans les macros
    • On peut faire du pattern-matching avec des slices
• Conclusion

L'édition 2018 du langage Rust est sortie. Ce journal est une traduction et un résumé de la documentation officielle.

Certaines nouveautés ne sont pas si nouvelles, mais c'est toujours utile d'en parler si vous n'avez pas trop suivi l'évolution du langage depuis un an.

Édition ? Jamais entendu parler de ça

Qu'est-ce qu'une édition en Rust ?

Il faut savoir qu'une nouvelle version de Rust sort toutes les 6 semaines. On peut donc vite être noyé dans les mises-à-jour et les nouveautés. Afin de pouvoir visualiser les nouveautés avec plus de recul, et surtout d'ajouter certains breaking changes, le langage a (et aura) une nouvelle édition tous les 2 ou 3 ans.

La première édition était celle de 2015, qui regroupe la version 1.0 et une partie des mises-à-jour qui ont suivi. Cette version 2018 regroupe les dernières nouveautés, dont une partie n'est pas accessible dans l'édition 2015.

Quid de la stabilité ?

Entendre parler de breaking change peut faire peur, mais l'équipe de Rust a bien étudié son coup. L'unité de compilation en Rust est le crate (caisse en anglais) contrairement au C par exemple, où c'est le fichier. Chacun des crates d'un projet peut utiliser une édition différente du langage. On peut créer un nouveau crate 2015 et utiliser un crate 2018, qui utilise de nouveaux mots-clés par exemple, sans problèmes.

Le langage peut donc avoir des changements incompatibles sans que le code des utilisateurs n'en soit impacté.

En revanche, la bibliothèque standard ne peut en aucun cas avoir de breaking changes puisque si on change un type entre les éditions 2015 à 2018 par exemple, on ne peut plus passer une instance de ce type d'un crate à l'autre.

Comment utiliser cette édition ?

Dans les faits, ça veut dire que :

• Si vous voulez créer un nouvau projet, la commande cargo new créera un nouveau projet directement avec l'édition 2018. Concrètement, une nouvelle ligne est ajoutée dans le manifeste : edition = "2018"
• Si vous voulez mettre à jour un projet existant, il suffit de lancer la commande cargo fix --edition, ce qui va rendre les sources compatibles avec la dernière version.

Quelles sont les nouveautés ?

Venons-en au fait: quoi de neuf ?

Le système de modules

Les chemins

Le système de modules de la première édition faisait partie de ces choses difficiles à appréhender pour un débutant. Par exemple, selon qu'on utilisait un chemin dans une instruction use ou dans le code, ça pouvait compiler ou pas : le système de chemins pouvait sembler quelque peu incohérent. Dans l'édition 2018, tout est harmonisé : dans tous les cas, il faut utiliser crate comme racine du chemin pour se référer au module de base, et self pour le module courant. L'équipe de Rust est encore en débat pour savoir lequel des deux sera le comportement par défaut en cas de chemin relatif.

Les dépendances externes

La directive extern crate n'est plus nécessaire quand on veut utiliser une dépendance externe. Effectivement, ça faisait doublon puisque l'information est dans tous les cas dans le manifeste du projet Cargo.toml.

Les macros

Les macros, qu'elles soit procédurales ou non, ressemblent de plus en plus aux autres items du langage. On les importe maintenant dans le scope avec use, tout comme le reste : use mon::chemin::ma_macro;. Il y a encore du travail à faire sur les macros (hygiène, macros 2.0, …), mais elles pourront bientôt s'utiliser à tout point de vue comme des fonctions.

Quel fichier pour quel module

Maintenant, quand on veut mettre un sous-module dans un dossier, on n'a plus besoin du fichier mod.rs. Avant :

|
|- foo
|  |- mod.rs
|  |- autre_module.rs

Après :

|
|- foo.rs
|- foo
|  |- autre_module.rs

Ça permet de ne pas avoir tout un tas de fichiers mod.rs ouverts en même temps dans un éditeur (c'est vrai qu'on s'y perdait vite dans les gros projets).

De nouveaux types de modifieurs de visibilité

On peut mettre tout un tas de paramètres au mot clés pub pour un comportement un peu similaire au mot-clé friend en C++ : pub(crate), pub(a::b::c), etc. Il y a plus de détails dans la documentation du langage.

Directive use imbriquée

L'utilisation de use est plus souple. On peut maintenant marquer :

use std::{
    fs::File,
    io::Read,
    path::{
        Path,
        PathBuf
    }
};

Système de trait

Maintenant, il existe une syntaxe plus explicite et symétrique pour le dispatch dynamique vs statique :

// Géré à la compilation via monomorphisation :
fn foo(it: impl Iterator<Item = i32>) {
    for i in it {
        // ...
    }
}

// Géré pendant le runtime :
fn foo(it: Box<dyn Iterator<Item = i32>>) {
    for i in it {
        // ...
    }
}

La notation impl peut remplacer l'introduction d'un type générique (sauf dans les cas les plus complexes) en simplifiant la syntaxe. Ainsi, on aurait pu écrire :

fn foo<T>(it: T) where T: Iterator<Item = i32> {
    for i in it {
        // ...
    }
}

Simplification concernant les types lifetime

Lifetimes non lexicaux

Il y aurait beaucoup à dire à ce sujet, mais le borrow-checker (la partie du compilateur qui vérifie la sécurité du code) a été réimplémenté avec un algorithme différent. Il est maintenant plus souple, dans le sens ou il élimine plus de faux-positifs. Le précédent borrow-checker refusait certaines choses qui auraient dû être acceptées, par exemple :

let mut v = vec![1, 2, 3];
v.push(v.len())

Pattern matching plus intelligent

Le pattern matching n'oblige plus à faire des contorsions quand on match des références. Par exemple, avant on devait écrire :

let s: &Option<String> = &Some("hello".to_string());

match s {
    // On match s avec `&Some(_)` puisque s est une référence,
    // et pour la valeur interne on doit marquer `ref s`
    // puisqu'on ne peut pas déplacer le contenu d'une donnée
    // qui a été empruntée.
    &Some(ref s) => println!("s is: {}", s),
    _ => (),
};

En 2018, le code est plus simple, et plus intuitif :

let s: &Option<String> = &Some("hello".to_string());

match s {
    // Le compilateur comprend qu'on veut récupérer une référence
    // sur la valeur interne. La référence est pour ainsi dire passée
    // de l'Option à la valeur interne.
    Some(s) => println!("s is: {}", s),
    _ => (),
};

Simplification dans l'écriture des lifetimes génériques

Il s'agit d'un certains nombre de cas de figure où l'écriture était inutile, redondante, etc. En vrac :

• Tout comme les types de données, les types lifetime ont un identifieur anonyme '_. On l'utilise dans le cas d'un type avec un lifetime générique : Foo<'_>.
• Plus besoin de spécifier le lifetime générique quand on implémente un trait pour une référence : impl Trait for &Foo { /* etc. */ }
• Plus besoin de spécifier l'interdépendance des types données génériques avec les types lifetime génériques dans le cas d'une struct, par exemple : T: 'a.

Autres

Voici une liste de fonctionalités plus complexes, et donc que je détaillerai moins :

Notations pour le code asynchrone

Il sera plus simple d'écrire du code asynchrone grâce aux mots-clés async et await. Cette fonctionalité n'est pas encore stable, mais les mots-clés sont réservés pour l'édition 2018.

SIMD, 128 bits

Sont supportés officiellement les opérations SIMD et les types entiers sur 128 bits i128 et u128.

Macros procédurales

Tous les types de macros procédurales ont été stabilisés pour 2018 :
- les instructions derive : #[derive(Foo)]
- les attributs : #[foo(/* etc. */)]
- les macros appelées comme des fonctions : foo!(/* etc. */)

Zero ou une occurence dans les macros

Maintenant, les mêmes répéteurs que pour les regexs existent dans l'implémentation des macros :
- * pour zero répétition ou plus,
- + pour une répétition ou plus,
- ? pour zero ou une occurence.

On peut faire du pattern-matching avec des slices

fn main() {
    bonjour(&[]);
    // sortie: Hé, il n'y a personne ici.

    bonjour(&["Linus"]);
    // sortie: Coucou, Linus, j'ai l'impression que tu es tout seul.

    bonjour(&["Linus", "Richard"]);
    // sortie: Coucou, Linus et Richard. Content de voir que vous êtes au moins 2 !

    bonjour(&["Linus", "Richard", "Lennart"]);
    // sortie: Bonjour à tous, j'ai l'impression que nous sommes 3 aujourd'hui.
}

fn bonjour(people: &[&str]) {
    match people {
        [] => println!("Hé, il n'y a personne ici."),
        [tout_seul] => println!("Coucou, {}, j'ai l'impression que tu es tout seul.", tout_seul),
        [premier, second] => println!("Coucou, {} et {}. \
            Content de voir que vous êtes au moins 2 !", premier, second),
        _ => println!("Bonjour à tous, j'ai l'impression que nous sommes {} aujourd'hui.", people.len()),
    }
}

Conclusion

Le langage a beaucoup avancé au cours des 3 dernières années, avec de nouvelles fonctionalités excitantes, et des simplifications bienvenues. Je ne peux que vous conseiller de lire la documentation officielle à ce sujet.

La communautés attend encore avec impatience bien d'autres choses (je vous invite à voir la liste des RFC pour vous faire une idée) et je suis convaincu que la prochaine édition sera tout aussi riche en nouveautés que celle-ci.