Rust planeja tipos imóveis e destrutores garantidos para 2026 e 2027

O projeto Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) → aceitou uma meta para o ciclo de 2026 e 2027 chamada Immobile types and guaranteed destructors. A ideia central é tornar explícitas, via traits, duas capacidades que hoje o compilador assume valer para todos os tipos: poder ser movido (realocado na memória) e poder ser esquecido com mem::forget, sem rodar o destrutor. O ponto de contato da proposta é @lcnr, e o status já consta como Accepted.

O que muda no modelo de tipos

Hoje Rust parte do princípio de que qualquer valor pode ser movido e de que mem::forget é uma operação segura. Segundo a proposta, essas suposições estão embutidas na linguagem: atribuição move valores, e esquecer um valor não exige rodar seu destrutor. A meta introduz novos auto-traits que descrevem o que é possível fazer com um tipo, num enquadramento positivo em que traits representam capacidades:

• Move: o tipo pode ser realocado na memória.
• Destruct: o tipo pode ser destruído implicitamente (destrutor roda ao sair de escopo).
• Forget: o tipo pode ser esquecido via mem::forget sem rodar o destrutor.

O documento posiciona esse trabalho como continuidade do Sized hierarchy, que relaxou a premissa de que todo tipo tem tamanho conhecido em tempo de compilação. A assinatura proposta para o trait é unsafe auto trait Move {}, e tipos que implementam !Move não podem ser movidos, mantendo endereço estável por toda a existência.

Por que isso importa para quem escreve async

Um dos motivadores é o problema dos tipos imóveis. Muitos futures async querem ser autorreferenciais, mas tipos autorreferenciais não podem ser movidos com segurança. A solução atual é Pin, que, nas palavras da proposta, codifica imovibilidade como propriedade de places e não de tipos, o que gera complexidade significativa.

O trait Move encoda imovibilidade como propriedade do tipo, algo descrito como mais simples que Pin. A meta chega a declarar o objetivo eventual de descontinuar Pin no Rust. Vale notar que a proposta se apresenta explicitamente como alternativa à iniciativa Pin Ergonomics de 2025H2, e não como complemento: em vez de mexer na linguagem para fazer Pin funcionar, o time avalia que o problema está no próprio Pin.

Destrutores garantidos e scoped spawn

O segundo eixo é o !Forget. Alguns tipos precisam ter seus destrutores executados: o documento cita uma Transaction que exige commit() ou rollback() antes da limpeza, e um handle de tarefa que precisa dar join antes do escopo terminar. Como mem::forget é seguro hoje, Rust não consegue garantir que o destrutor rode.

Com !Forget, seria possível construir safe scoped spawn em async: o handle da tarefa tem um destrutor que faz o join, e como o handle não pode ser esquecido, esse join é garantido. Isso destrava um padrão hoje impossível em Rust seguro, já que esquecer o handle poderia deixar a tarefa acessar referências penduradas depois que o escopo acabou.

Escopo do ano e testes no kernel

Os itens de trabalho incluem implementação de Move no compilador (por @lcnr e @nia-e), a RFC do Move (@yoshuawuyts) e uma exploração de design para destrutores garantidos (@nikomatsakis). Um ponto de validação relevante é o teste no Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → kernel, descrito na fonte como usuário importante do Rust que usa muitas estruturas autorreferenciais, sob responsabilidade de @BennoLossin.

A meta deixa explícito o que fica fora de escopo neste ano: qualquer mudança no trait Future. Ele é o único trait estável em Rust que depende de Pin e exigiria uma história de migração própria, tratada como projeto separado. Tanto o time de lang quanto o de types marcaram o pedido de suporte como Large.

O que observar

Para quem constrói software no Brasil com Rust em produção, especialmente em código async e sistemas de baixo nível, a mudança promete mais previsibilidade sem custo de runtime: garantias sobre movimentação e limpeza passam a ser verificadas em tempo de compilação. Ainda é uma meta de projeto com horizonte de dois anos, então nada disso está estável. Quem quiser acompanhar pode seguir a tracking issue #635 e o canal Zulip #t-lang/move-trait.

Fonte: Hacker News