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á?