Rust stabilise le type never après dix ans et cinq tentatives

Le type never de Rust est enfin stable. La pull request qui l'a fait, numérotée 155499, a été fusionnée dans rust-lang/rust le 24 août 2026 et est prévue pour Rust 1.100.0. Elle emporte avec elle une rupture de compatibilité. C'est donc une note de version à lire, pas à parcourir.

Le type never s'écrit avec un simple point d'exclamation. C'est le type d'une expression qui ne produit jamais de valeur, parce qu'elle panique, boucle indéfiniment, ou sort de la fonction avant. Rust s'en sert en interne depuis des années pour typer ces impasses. Ce qui manquait, c'était la possibilité de l'écrire dans votre propre code et de compter sur lui.

Ce qui change réellement

Trois choses arrivent ensemble, selon la pull request.

• Le type never est stable, et la PR clôt les tickets de suivi numérotés 35121 et 148922.
• Toutes les éditions de Rust résolvent désormais un type never non contraint vers le type never, au lieu de se replier sur le tuple vide. C'est la partie qui casse.
• Le std::convert::Infallible de la bibliothèque standard devient un simple alias de type pour le type never.

Le changement de repli demande à être déplié, car c'est lui qui peut modifier le comportement de votre code. Le compilateur atteint parfois un endroit où une valeur ne peut jamais exister et où aucun type n'a été fixé. Historiquement, il choisissait là le tuple vide, écrit comme une paire de parenthèses. Il choisit maintenant le type never. Comme l'ancien repli ne se produit plus, la PR supprime aussi l'avertissement qui signalait le code en dépendant, nommé dependency_on_unit_never_type_fallback.

C'est un vrai changement de comportement, et le projet Rust l'a mesuré. La PR indique que crater a fait apparaître au départ 3 277 régressions. crater est l'outil qui compile une large part des crates publiées face à un compilateur proposé. Le changement final a tenu en 18 commits de correctifs, de tests et de documentation.

Dix ans de tentatives

Le ticket de suivi raconte l'histoire longue. Le ticket 35121 a été ouvert le 29 juillet 2016 pour suivre la RFC 1216, la proposition de promouvoir le point d'exclamation d'une notation spéciale à un vrai type. Cela fait dix ans d'ouverture. L'auteur de la PR de cette semaine écrit sur son blog qu'il y a eu cinq tentatives de stabilisation antérieures, et que cet effort seul a pris plus de deux ans.

Jalon consigné dans le ticket de suivi	Ce qui s'est passé
RFC 1216, ticket 35121 ouvert en juillet 2016	Promouvoir le type never en vrai type
PR 35162	Première implémentation
PR 65355	Stabilisation visant Rust 1.41.0
PR 67224	Cette stabilisation annulée après des régressions
Ticket 123748	Repli modifié d'abord dans l'édition Rust 2024
PR 155499, fusionnée en août 2026	Repli généralisé, type never stabilisé

L'annulation est l'entrée instructive. La stabilisation a été tentée, de vraies crates ont cassé, et le changement a été ressorti. Les blocages consignés sur le ticket sont tous des rapports de régression, numérotés 66757, 67225 et 65992. Le dernier traite de la façon dont les expressions divergentes doivent se replier. Le chemin de contournement a été de modifier le repli dans une seule édition d'abord, puis de le généraliser une fois que l'écosystème l'avait absorbé.

Ce que cela signifie pour les développeurs

N'attendez pas 1.100.0 pour le découvrir. Compilez votre crate sur nightly dès maintenant et lisez les diagnostics. Les changements de repli sont cette classe de rupture qui compile silencieusement à un endroit et échoue à un autre. Surveillez le code générique où un paramètre de type n'est fixé que par une expression qui panique ou qui sort tôt. C'est exactement là que le compilateur choisissait le tuple vide pour vous.

Le changement sur Infallible est celui à chercher par grep. Si vos types d'erreur utilisent std::convert::Infallible, c'est désormais un alias et non plus une énumération distincte. Les alias se comportent différemment à deux endroits précis. Vous ne pouvez plus écrire une implémentation de trait distincte pour lui, séparée du type never, et tout bras de match qui le construit mérite un second regard. La plupart du code ne sera pas affecté. Mais une bibliothèque qui implémente des conversions sur les deux noms devrait vérifier l'absence de conflit avant que 1.100.0 n'arrive en stable.

Il y a aussi un nettoyage utile. Si vous avez fait taire ou contourné l'avertissement dependency_on_unit_never_type_fallback, ces contournements sont désormais du poids mort, et le lint qui les justifiait a disparu. Cherchez-le, retirez l'échafaudage, et laissez le vérificateur de types travailler.

La leçon plus large porte sur la manière dont Rust livre des ruptures. Le schéma vaut d'être copié si vous maintenez une bibliothèque avec de vrais utilisateurs. Placez le nouveau comportement derrière une frontière d'adhésion explicite, dans le cas de Rust une édition. Mesurez le rayon d'impact face à du code réellement publié. Ne le généralisez qu'une fois ce nombre redescendu. Dix ans paraissent lents de l'extérieur. Une stabilisation annulée et une exécution de crater signalant 3 277 crates en expliquent l'essentiel.