Rust estabiliza o tipo never após dez anos e cinco tentativas

O tipo never do Rust finalmente está estável. O pull request que fez isso, de número 155499, foi mesclado no rust-lang/rust em 24 de agosto de 2026 e está marcado para o Rust 1.100.0. Ele traz consigo uma quebra de compatibilidade. Esta é, portanto, uma nota de versão para ler, não para passar o olho.

O tipo never é escrito com um único ponto de exclamação. É o tipo de uma expressão que nunca produz valor, porque entra em pânico, roda para sempre, ou sai da função antes. O Rust o usa internamente há anos para tipar esses becos sem saída. O que faltava era poder escrevê-lo no seu próprio código e contar com ele.

O que mudou de fato

Segundo o pull request, três coisas chegam juntas.

• O tipo never está estável, e o PR fecha as issues de acompanhamento de números 35121 e 148922.
• Toda edição do Rust agora resolve um tipo never sem restrição para o tipo never, em vez de recuar para a tupla vazia. Essa é a parte que quebra.
• O std::convert::Infallible da biblioteca padrão passa a ser um simples alias de tipo para o tipo never.

A mudança de recuo precisa ser destrinchada, porque é ela que pode alterar o que seu código faz. Às vezes o compilador chega a um ponto onde um valor nunca pode existir e nenhum tipo foi fixado. Historicamente ele escolhia ali a tupla vazia, escrita como um par de parênteses. Agora escolhe o tipo never. Como o recuo antigo não acontece mais, o PR também remove o aviso que marcava o código que dependia dele, chamado dependency_on_unit_never_type_fallback.

Essa é uma mudança real de comportamento, e o projeto Rust a mediu. O PR relata que o crater apontou no começo 3.277 regressões. O crater é a ferramenta que compila uma fatia grande das crates publicadas contra um compilador proposto. A mudança final ficou em 18 commits de correções, testes e documentação.

Dez anos de tentativas

A issue de acompanhamento conta a história longa. A issue 35121 foi aberta em 29 de julho de 2016 para acompanhar a RFC 1216, a proposta de promover o ponto de exclamação de notação especial para tipo real. São dez anos aberta. O autor do PR desta semana escreve no seu blog que houve cinco tentativas anteriores de estabilização, e que só este esforço levou mais de dois anos.

Marco registrado na issue de acompanhamento	O que aconteceu
RFC 1216, issue 35121 aberta em julho de 2016	Promover o tipo never a tipo real
PR 35162	Primeira implementação
PR 65355	Estabilização visando o Rust 1.41.0
PR 67224	Essa estabilização revertida após regressões
Issue 123748	Recuo alterado primeiro dentro da edição Rust 2024
PR 155499, mesclado em agosto de 2026	Recuo tornado universal, tipo never estabilizado

A reversão é o item instrutivo. A estabilização foi tentada, crates reais quebraram, e a mudança foi retirada. Os bloqueios registrados na issue são todos relatos de regressão, de números 66757, 67225 e 65992. O último trata de como expressões que divergem devem recuar. O caminho para contornar o problema foi alterar o recuo primeiro em uma edição, e torná-lo universal depois que o ecossistema o absorveu.

O que isso significa para desenvolvedores

Não espere o 1.100.0 para descobrir. Compile sua crate no nightly agora e leia os diagnósticos. Mudanças de recuo são a classe de quebra que compila em silêncio num lugar e falha em outro. Preste atenção a código genérico onde um parâmetro de tipo só é fixado por uma expressão que entra em pânico ou sai cedo. É exatamente ali que o compilador costumava escolher a tupla vazia para você.

A mudança no Infallible é a que se deve procurar com grep. Se seus tipos de erro usam std::convert::Infallible, agora ele é um alias e não mais um enum próprio. Aliases se comportam de forma diferente em dois lugares específicos. Você não pode mais escrever uma implementação de trait própria para ele, separada do tipo never, e todo braço de match que o constrói merece um segundo olhar. A maior parte do código não será afetada. Mas uma biblioteca que implementa conversões sobre os dois nomes deveria checar se há conflito antes de o 1.100.0 chegar ao stable.

Há também uma limpeza que vale a pena. Se você silenciou ou contornou o aviso dependency_on_unit_never_type_fallback, esses contornos agora são peso morto, e o lint que os justificava não existe mais. Procure por ele, remova o andaime e deixe o verificador de tipos trabalhar.

A lição maior é sobre como o Rust entrega quebras de compatibilidade. O padrão vale copiar se você mantém uma biblioteca com usuários reais. Coloque o comportamento novo atrás de uma fronteira de adesão explícita, que no caso do Rust é uma edição. Meça o raio de impacto contra código realmente publicado. E só o torne universal quando esse número cair. Dez anos parecem lentos de fora. Uma estabilização revertida e uma execução do crater apontando 3.277 crates explicam a maior parte.