Avec Rust 1.67.0, un attribut must_use sur les fonctions asynchrones fait désormais ce à quoi vous vous attendez.

Les types entiers ont maintenant des méthodes de logarithme (entier)

Avec Rust 1.67.0, un attribut must_use sur les fonctions asynchrones fait désormais ce à quoi vous vous attendez.
Les types entiers ont maintenant des méthodes de logarithme (entier) : ilog, ilog10, ilog2.

#[must_use] efficace sur async fn

Les fonctions [C]async[/] annotées avec #[must_use] appliquent désormais cet attribut à la sortie de l'impl Future renvoyé. Le trait Future lui-même est déjà annoté avec #[must_use], donc tous les types implémentant Future sont automatiquement #[must_use], ce qui signifiait qu'auparavant il n'y avait aucun moyen d'indiquer que la sortie de Future est elle-même significative et devrait être utilisée dans certains chemin.

Avec 1.67, le compilateur avertira désormais si la sortie n'est pas utilisée d'une manière ou d'une autre.

Implémentation mise à jour de std::sync::mpsc

La bibliothèque standard de Rust avait un canal multi-producteur et mono-consommateur bien avant la version 1.0, mais dans cette version, l'implémentation est commutée pour être basée sur le canal crossbeam. Cette version ne contient aucune modification de l'API, mais la nouvelle implémentation corrige un certain nombre de bogues et améliore les performances et la maintenabilité de l'implémentation.

Les utilisateurs ne devraient pas remarquer de changements significatifs de comportement à partir de cette version.

API stabilisées

• {integer}::checked_ilog
• {integer}::checked_ilog2
• {integer}::checked_ilog10
• {integer}::ilog
• {integer}::ilog2
• {integer}::ilog10
• NonZeroU*::ilog2
• NonZeroU*::ilog10
• NonZero*::BITS
  

Rust dans l'actualité

« La sécurisation des logiciels via le langage Rust n'est pas supérieure à celle offerte par le C++ »

Mark Russinovich de Microsoft a déclaré au troisième trimestre de l’année précédente que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. » Motif : le Rust offre de meilleures garanties de sécurisation des logiciels que les langages C ou C++. La position reprise quelques mois plus tard par la NSA a récemment trouvé un contradicteur.

Sans surprise, le créateur du langage C++ a déclaré : « la sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++. »

Bjarne Stroustrup s’inscrit en faux avec le fait que la publication de la NSA limite la notion de sécurisation des logiciels à celle de sécurisation de la mémoire. En réalité, cet aspect est un dénominateur commun de toutes les publications qui conseillent de mettre le C ou le C++ au rebut au profit du langage Rust en raison des garanties de sécurisation des logiciels que plusieurs grandes entreprises (Microsoft, Amazon, etc.) lui reconnaissent.

« Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique », indique-t-il. Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.

Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.

L’équipe de Google dont la publication est parue au troisième trimestre de l’année précédente est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.

[CODE=Rust]#include <type_traits>
#include <utility>
#include <assert.h>
#include <stddef.h>
enum NoRefs {};
enum HasMutRef {};
enum HasRefs {};
template <class T, typename Mode>
class Own;
template <class T>
class MutRef;
template <class T>
class Ref;
template <class T, typename... Args>
inline Own<T, NoRefs> make(Args... args) {
return Own<T, NoRefs>(std::forward<Args>(args)...);
}
template <class T>
inline Own<T, NoRefs> consume(Own<T, HasMutRef> own, MutRef<T> ref) {
return Own<T, NoRefs>(std::move(own));
}
template <class T>
inline Own<T, NoRefs> consume(Own<T, HasRefs> own) {
return Own<T, NoRefs>(std::move(own));
}
template <class T>
std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own) {
T* t = own.t_;
own.t_ = nullptr;
return std::make_pair(Own<T, HasMutRef>(t), MutRef<T>(t));
}
template <class T>
std::pair<Own<T, HasRefs>, MutRef<T>> ref(Own<T, NoRefs> own) {
T* t = own.t_;
own.t_ = nullptr;
return std::make_pair(Own<T, HasRefs>(t), Ref<T>(t));
}
// No refs exist.
template <class T>
class [[clang::trivial_abi]] Own<T, NoRefs> {
public:
template <typename... Args>
Own(Args... args) : t_(new T(std::forward<Args>(args)...)) {}
~Own() { delete t_; }
Own(Own<T, NoRefs>&& other) : t_(other.t_) { other.t_ = nullptr; }
T& operator*() const noexcept { return *t_; }
T* operator->() const noexcept { return t_; }
private:
friend Own<T, NoRefs> consume<T>(Own<T, HasMutRef> own, MutRef<T> ref);
friend Own<T, NoRefs> consume<T>(Own<T, HasRefs> own);
friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own);
friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own);
Own(Own<T, HasMutRef>&& own) : t_(own.t_) {}
Own(Own<T, HasRefs>&& own) : t_(own.t_) {}
T* t_;
};
// A mut ref exists.
template <class T>
class [[clang::trivial_abi]] Own<T, HasMutRef> {
public:
T& operator*() const noexcept { return *t_; }
T* operator->() const noexcept { return t_; }
private:
friend class Own<T, NoRefs>;
Own(T* t) : t_(t) {}
~Own() {}
T* t_;
};
// Non-mut refs exist.
template <class T>
class [[clang::trivial_abi]] Own<T, HasRefs> {
public:
T& operator*() const noexcept { return *t_; }
T* operator->() const noexcept { return t_; }
Ref<T> ref() { return Ref<T>(t_, &count_); }
private:
friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own)[/clang::trivial_abi]]...