Por que tipos mutáveis e imutáveis nunca são subtipos um do outro

Isso explica por que o compilador aceita passar uma &mut T onde se espera uma &T (o chamado reborrow, algo como &*minha_ref_mut), mas nunca o contrário sem unsafe:

fn le(valor: &i32) -> i32 { *valor }
fn escreve(valor: &mut i32) { *valor += 1; }

let mut x = 10;
let r = &mut x;
le(r); // ok: &mut i32 vira &i32 nesse ponto
// escreve precisaria de &mut i32; um &i32 nunca vira isso de volta

Não é subtipagem clássica no sentido do post (Rust não tem hierarquia de classes para tipos primitivos), mas o raciocínio de contrato é o mesmo: quem tem &mut T pode abrir mão temporariamente da capacidade de escrever e se comportar como &T, porque isso só restringe o que pode fazer. O caminho inverso violaria a garantia que todo &T carrega, a de que o valor não muda enquanto a referência existir. É a mesma regra do car/cdr do post, com nomes diferentes.

Um efeito prático dessa regra aparece em HashMap. Se a chave usa RefCell ou outra forma de mutabilidade interna e alguém muda o valor depois de inserido, o hash calculado na inserção não bate mais com o hash recalculado na busca, e a entrada some silenciosamente. A documentação da própria std alerta sobre isso: é o hash consing do post quebrando na prática, décadas depois, num container bem mais moderno que um par de Scheme.

Traits em vez de hierarquia: a saída que o post já prevê

O artigo original também explica por que isso não condena a mutabilidade e a imutabilidade a viverem sem nenhum código compartilhado: linguagens estaticamente tipadas resolvem isso com classes de tipo (o trabalho de Wadler e Blott é citado diretamente), que o post equipara a interfaces, traits ou roles conforme a linguagem. Traits em Rust são exatamente esse mecanismo. Um trait pode declarar um método que recebe &self e outro, num trait separado, que recebe &mut self, sem que um dependa do outro formar uma cadeia de subtipos.

Index e IndexMut da std são o exemplo mais direto: Vec implementa os dois, mas são traits distintos, e uma função que só recebe &Vec nunca consegue indexar por IndexMut, porque o compilador nem oferece a assinatura. É o mesmo desenho do post, com car/cdr no papel de Index::index e set-car!/set-cdr! no papel de IndexMut::index_mut.

O que fica para quem vem de outra linguagem

Em Java ou TypeScript, é comum tratar "visão somente leitura de um objeto mutável" como se fosse um subtipo por convenção, um Readonly que o próprio desenvolvedor promete respeitar, sem o compilador provar nada. Rust recusa esse atalho: a separação entre &T e &mut T é imposta pelo borrow checker, não por boa vontade, e é ela que sustenta a promessa de concorrência sem data races que a linguagem vende.

Fica em aberto, e o post não entra nisso, como esse raciocínio interage com a variância de lifetimes, onde Rust de fato permite um tipo de subtipagem (&'long T pode substituir &'short T). É um eixo diferente do de mutabilidade, mas é o próximo lugar óbvio para quem quiser aprofundar como o sistema de tipos de Rust decide, formalmente, o que pode substituir o quê.

Fonte: Hacker News