Dopo dieci anni e cinque tentativi falliti, Rust 1.100 stabilizza il tipo never (`!`), il tipo senza valori che rappresenta calcoli che non terminano normalmente. La versione consente di scriverlo in qualsiasi posizione di tipo e trasforma `Infallible` in un suo alias; modifica inoltre l’inferenza del tipo never nelle edizioni precedenti alla 2024.
Il team di Rust ha pubblicato Rust 1.100.0 nel canale stabile il 12 novembre 2026. Chi ha installato una versione precedente con rustup può aggiornare con `rustup update stable`; il team invita inoltre a provare le versioni future tramite i canali beta o nightly e a segnalare gli errori riscontrati.
`!` non è più limitato al tipo di ritorno
Il tipo never, scritto `!`, è il tipo canonico senza valori possibili. Descrive calcoli che divergono: non producono un valore e il codice che potrebbe seguirli diventa irraggiungibile. Rust assegnava già questo tipo alle espressioni che interrompono il flusso, come `return`, `break` e `std::process::exit`.
Prima di questa versione, `!` poteva essere osservato in quei contesti e persino scritto come tipo di ritorno di una funzione, ma non poteva essere nominato ovunque. Rust 1.100 elimina questa limitazione: ora può comparire, per esempio, come tipo di errore in `Result`. Il team presenta questa modifica come il completamento dell’obiettivo del progetto di stabilizzare il tipo.
Rust consentiva già di coercire `!` a qualsiasi altro tipo. Poiché non è possibile ottenere un valore di tipo never, un ramo divergente può essere usato dove gli altri rami producono un valore. Perciò un’espressione `match` può restituire un `u32` in un ramo ed eseguire `return` in un altro: quest’ultimo non fornisce un valore, ma il suo tipo `!` viene convertito nel tipo atteso.
La distinzione è importante perché il tipo never non è semplicemente un altro tipo vuoto. La coercizione di `!` a qualsiasi tipo consente alle espressioni che non proseguono l’esecuzione di essere usate in contesti con un tipo di risultato concreto. La novità di Rust 1.100 è che ora il tipo può essere nominato esplicitamente, oltre a intervenire in queste regole di controllo del flusso.
`Infallible` diventa `!`
Rust 1.100 trasforma `Infallible` in un alias del tipo never. Il tipo `Infallible` serve a esprimere che un’operazione non può fallire; trasformandolo in un alias, le API esistenti che lo utilizzano diventano compatibili con quelle che usano `!`. Il team afferma che questo era il piano fin dall’introduzione di `Infallible` e che realizzarlo è stato uno dei motivi per cui la stabilizzazione si è rivelata complessa.
La modifica a `Infallible` comporta un cambiamento di compatibilità: il fallback del tipo never passa da `()` a `!` anche nelle edizioni 2015, 2018 e 2021. Nell’edizione 2024 questo comportamento era già stato introdotto. La modifica può influire sul codice in casi poco frequenti, per esempio quando si ignora il risultato di una funzione che restituisce un parametro generico; inoltre, il compilatore potrebbe identificare più codice come irraggiungibile.
Il team afferma di aver cercato di ridurre l’impatto inviando in anticipo avvisi di compatibilità futura e pubblicando correzioni per i crate pubblici interessati. Se una dipendenza non funziona a causa di problemi legati al tipo never, consiglia di provare ad aggiornarla: potrebbe già essere disponibile una versione corretta.
Una modifica sviluppata in più fasi
La pull request che ha portato la stabilizzazione nel repository è stata la pull request #155499, aperta da WaffleLapkin. Secondo il tracciamento di GitHub, rust-bors ha integrato 18 commit in `rust-lang:main`. La proposta includeva la stabilizzazione di `!`, la trasformazione di `Infallible` in un alias e la modifica del fallback del tipo never in `!` in tutte le edizioni.
La cronologia mostra che il processo ha richiesto modifiche e revisioni. Nell’aprile 2026 è stato avviato un esperimento di Crater, lo strumento che verifica le modifiche su parti dell’ecosistema Rust. Il risultato pubblicato ha registrato 3.277 regressioni e zero correzioni su un totale di 9.024 risultati; il commento avvertiva che 1.149 risultati erano spurii in un elenco di nuovi tentativi e suggeriva di ripetere il test se quel numero fosse significativo.
Ad agosto, la pull request è rimasta senza approvazione durante un incidente relativo a un rollup e a un controllo di compatibilità di Cargo. La discussione ha rilevato che `core::convert::Infallible` esisteva ancora, pur passando da `pub enum` a `pub type`; un partecipante ha descritto l’avviso come un falso positivo di `cargo-semver-checks`. In seguito, la proposta è stata nuovamente approvata e integrata.
Il tracciamento delle note di rilascio, l’incidente #158197, ha documentato separatamente la stabilizzazione e le sue conseguenze sulla compatibilità. La bozza per il blog è stata preparata a settembre; sottolineava che il compilatore avrebbe potuto rilevare più codice irraggiungibile. La nota finale di Rust 1.100 mantiene anche la raccomandazione di aggiornare le dipendenze pubbliche per cui sono state rilasciate correzioni.
Altre modifiche a Cargo e alla libreria standard
Il tipo never condivide la scena con altre novità di Rust 1.100. La versione stabilizza parti fondamentali dell’API `Allocator`, che consentono agli autori di librerie di definire allocatori personalizzati per alcuni tipi della libreria standard, attualmente `Vec` e `Box`. Il team la descrive come la base dell’obiettivo Allocators 1.0; l’ampliamento dell’API e il suo utilizzo in altre collezioni e tipi puntatore restano attività future.
Arriva anche `core::mem::DropGuard`, un tipo ausiliario che esegue una closure quando viene distrutto. Riceve una variabile e una closure, implementa `Deref` e `DerefMut` per consentire di continuare a usare la variabile e la consuma quando il guard viene eliminato. Il metodo `dismiss` permette di recuperare il valore senza eseguire il distruttore, un’opzione utile per annullare le modifiche se un’operazione fallisce.
Un’altra nuova API, `std::mem::conjure_zst`, offre una funzione specifica per creare valori di tipi di dimensione zero quando si sa che è sicuro farlo. Il team la presenta come alternativa a diverse tecniche basate su transmutazioni o su `MaybeUninit`. La funzione è `unsafe`: alcuni tipi di dimensione zero fungono da marcatori di condizioni necessarie per la sicurezza; il blog cita come esempio il token `Python
Fonti: The Rust Blog, GitHub, GitHub, byteiota | From Bits to Bytes
