Curiosidades da linguagem Rust

Como a linguagem Rust impede, na compilação, a ocorrência de acessos inválidos a memória

Uma das características que mais gosto em Rust é que o compilador faz um enorme esforço para detectar prováveis erros de tempo de execução na compilação.

O preço que pagamos por essa “ajuda” do compilador é ter de nos adaptar a alguns conceitos exóticos em programação. Os benefícios são as garantias de que “erros bobos” não vão ocorrer em produção e que não teremos longas horas tentando reproduzir cenários exóticos que causam memory-leaks.

Um código simples que Rust não aceita

No post anterior, apresentamos o seguinte código que o compilador de Rust não aceita:

fn longest(x: &str, y: &str) -> &str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

Esse código, bem simples, recebe duas referências de strings e retorna aquela com mais bytes (assunto para outro post). Então, o que há de errado?

Por que Rust não compila meu código?

Para entender o que está acontecendo, temos que reafirmar duas características chave de Rust:

  • Em Rust, todo objeto no heap é de propriedade de uma, e somente uma, variável. Quando esta variável sai de contexto, Rust automaticamente remove o objeto da memória.
  • Para tornar a vida do programador um pouco menos difícil, Rust possui o conceito de referências semelhante ao que temos em C++. Porém, diferente de C++, há garantias, em tempo de compilação, de que as variáveis de referência não irão “viver” mais tempo que a variável com ownership do valor referenciado.

A função que propomos acima não consegue garantir a segunda característica, como fica explícito no exemplo abaixo:

fn main() {
  let r;
  let s1 = String::from("Elemar");
  {
    let s2 = String::from("Rodrigues Severo Jr");
    r = longest(&s1, &s2);
  }
  println!("r: {}", r);
}

fn longest(x: &str, y: &str) -> &str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

No exemplo, a variável r acabaria fazendo referência para s2, o que obviamente ocasionaria um erro em tempo de execução.

NOTA PESSOAL: Perdi a conta de quantas vezes escrevi código em outras linguagens que cai na armadilha apresentada acima. Por isso mesmo, gosto ainda mais do fato do compilador do Rust me alertar para esse problema em potencial.

Como deixar o compilador feliz

Concordamos que o problema do código em que estamos trabalhando é que não há garantias de que os objetos tenham o mesmo “tempo de vida”. Ou seja, um dos objetos pode “morrer” (ser desalocado) porque sua variável owner pode ter saído de contexto enquanto outra ainda faz referência para seu valor.

Felizmente, a linguagem Rust permite impor uma constraint em funções que podem causar esse tipo de problema.

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
  if x.len() > y.len() {
    x
  } else {
    y
  }
}

No código, o ‘a indica o lifetime das referências. No exemplo, indicamos que os dois parâmetros e o retorno estão em lifetimes compatíveis.

Gosto de como o compromisso de somente trabalhar com valores com lifetime compatível fica explícito no código. Você não?

Como entender mais sobre lifetimes em Rust?

Tanto o código que serve como exemplo, como boa parte da explicação que escrevemos aqui, foram inspirados no capítulo Validating References with Lifetimes (disponível on-line) do excelente livro The Rust Programming Language.

Se você prentende considerar Rust seriamente, recomendo muito fortemente a leitura do livro.

Era isso… por enquanto

Esse foi o segundo post com código aqui na Eximia! Também o segundo sobre Rust. Espero que tenham gostado. Que tal conversarmos sobre o que mostrei aqui nos comentários?

PS:  No post anterior, o Antonio Maniero fez considerações bem bacanas sobre vantagens e desvantagens do modelo de gestão de memória de Rust quando confrontado com ambientes com tracing GC, como .NET. Que tal dar uma lida?

PS 2: Criei um grupo no Facebook para compartilhar ideias e discutir mais sobre Rust. Que tal se inscrever lá?

Mais posts da série Curiosidades da linguagem Rust

2 Comentários
  1. Daniel Moreira Yokoyama

    Mais do que o conceito de Ownership, mas a ideia também de “borrowing” e “move”, e como o compilador restringe o acesso a valores de forma exclusiva para múltiplos readers, ou único writer.
    De forma que se existe um único writer, nenhum reader tem acesso, mas uma vez que o writer devolva o acesso, todos os leitores voltam a ter acesso ao valor atualizado.

  2. Antonio Maniero

    Obrigado pela menção, espero ter sido útil. Desta vez vou dizer que aconteceu o que eu achava, nunca vi um artigo que fosse fácil entender o funcionamento da especificação do tempo de vida. Eu entendi o artigo porque já conheço o assunto, mas quem viu pela primeira vez eu acho que não fica tão claro o que acontece ali. Mas esse é um problema geral, parece que ninguém consegue demonstrar isso facilmente, uma das críticas que faço ao mecanismo, até porque depois vem uma situações mais complexas, e tudo que é difícil de entender não é tão bom. Eu sei que depois que entende fica fácil usar (bom, eu usei pouco, mas ainda não é natural pra mim).

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *