Nesta aula, vamos explorar os aspectos avançados de lifetimes em Rust. Lifetimes são uma ferramenta fundamental para garantir a segurança de memória sem custo de runtime. Se você já entende o básico — como anotações de lifetime em funções e referências — agora é hora de mergulhar em situações mais complexas: como armazenar referências em structs, a lifetime especial 'static, bounds em generics e cenários com múltiplas referências. Vamos construir uma base sólida para que você possa escrever código idiomático e seguro, mesmo em situações desafiadoras.

Lifetimes em structs

Quando uma struct contém referências, é necessário declarar lifetimes para cada referência. Isso garante que a struct não sobreviva aos dados que referencia. A sintaxe é simples: adicionamos parâmetros de lifetime entre colchetes angulares após o nome do tipo. Por exemplo, uma struct que armazena uma referência a um str deve declarar uma lifetime 'a.

Vamos ver um exemplo prático:

struct Livro<'a> {
    titulo: &'a str,
    autor: &'a str,
}

fn main() {
    let titulo = String::from("Rust em Ação");
    let autor = String::from("João Silva");
    let livro = Livro {
        titulo: &titulo,
        autor: &autor,
    };
    println!("{}", livro.titulo);
}

Nesse código, a struct Livro tem uma lifetime 'a que deve ser igual para ambas as referências. Isso significa que titulo e autor devem viver pelo menos enquanto a struct existir. Se tentarmos mover as Strings antes de usar a struct, o compilador reclamará.

É importante notar que cada referência em uma struct pode ter sua própria lifetime, se necessário. Por exemplo, podemos ter duas referências com lifetimes diferentes para refletir que uma pode viver mais que a outra. Isso é útil quando uma referência aponta para um dado que tem um tempo de vida diferente de outro.

struct Par<'a, 'b> {
    primeiro: &'a str,
    segundo: &'b str,
}

fn main() {
    let a = String::from("primeiro");
    let b = String::from("segundo");
    let par = Par {
        primeiro: &a,
        segundo: &b,
    };
    println!("{}", par.primeiro);
}

Nesse caso, primeiro e segundo podem ter vidas diferentes, e o compilador garante que a struct não sobreviva a nenhuma delas.

'static

A lifetime 'static é especial: ela indica que a referência é válida por toda a duração do programa. Isso é comum para literais de string, que são embutidos no binário e vivem por todo o tempo de execução. Por exemplo, let s: &'static str = "Olá"; é válido.

No entanto, 'static não deve ser usado indiscriminadamente. Muitas vezes, ele aparece em APIs para indicar que o valor pode ser mantido indefinidamente, como em threads ou configurações globais. Mas cuidado: se você tentar devolver uma referência a um dado local como 'static, o compilador não permitirá, pois o dado será destruído ao final da função.

fn retorna_static() -> &'static str {
    let s = String::from("temporário");
    &s // Erro: s não vive o suficiente
}

Para criar uma referência 'static a partir de um valor alocado no heap, você pode usar Box::leak, que vaza a memória intencionalmente, fazendo com que ela viva para sempre. Isso é útil em raras situações, como ao criar uma configuração global.

fn configuracao_global() -> &'static str {
    let config = String::from("valor");
    Box::leak(config.into_boxed_str())
}

Essa técnica deve ser usada com moderação, pois vazar memória pode não ser desejável em todos os contextos.

Lifetime bounds

Em genéricos, podemos restringir os tipos para que satisfaçam certos lifetimes. Isso é chamado de lifetime bound. Por exemplo, ao definir um trait, podemos exigir que o implementador tenha uma lifetime específica.

Um exemplo comum é quando temos um tipo genérico que contém uma referência. Podemos usar um lifetime bound para garantir que a referência seja válida por um período mínimo. A sintaxe é T: 'a, o que significa que T deve viver pelo menos tanto quanto 'a.

fn imprimir_ref<'a, T: 'a>(x: &'a T) {
    println!("{:?}", x);
}

fn main() {
    let valor = 42;
    imprimir_ref(&valor);
}

Nesse exemplo, T pode ser qualquer tipo que viva pelo menos 'a, permitindo que a referência seja usada com segurança. Isso é especialmente importante em funções que retornam referências a dados genéricos.

Lifetime bounds também aparecem em traits. Por exemplo, o trait Display pode ser implementado para referências com lifetime, e podemos exigir que o tipo implemente Display para uma determinada lifetime.

fn imprimir_display<'a, T: Display + 'a>(x: &'a T) {
    println!("{}", x);
}

Isso garante que T implementa Display e que a referência é válida por 'a.

Casos complexos

Lifetimes podem se tornar complexos quando há múltiplas referências, dependências entre elas, ou quando trabalhamos com funções de alta ordem. Vamos analisar alguns cenários.

Múltiplas referências: Quando uma função recebe várias referências, podemos usar lifetimes diferentes para cada uma, mas também podemos usar a mesma lifetime se as referências devem viver tanto quanto a mais curta. Por exemplo:

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

Nesse caso, a lifetime 'a é o menor tempo de vida entre x e y, e o retorno é válido por esse período.

Referências em structs aninhadas: Quando temos structs que contêm outras structs com referências, precisamos propagar as lifetimes. Isso pode ficar verboso, mas é necessário para garantir a segurança.

struct Livro<'a> {
    titulo: &'a str,
}

struct Biblioteca<'a> {
    livros: Vec<Livro<'a>>,
}

fn main() {
    let titulo = String::from("Rust");
    let livro = Livro { titulo: &titulo };
    let biblioteca = Biblioteca { livros: vec![livro] };
    println!("{}", biblioteca.livros[0].titulo);
}

Aqui, Biblioteca deve ter a mesma lifetime 'a que os livros que contém.

Closures e lifetimes: Closures que capturam referências podem ter lifetimes inferidas, mas em casos complexos, podemos precisar anotar explicitamente. Por exemplo, ao retornar uma closure que captura uma referência, devemos especificar a lifetime.

fn criar_closure<'a>(s: &'a str) -> impl Fn() -> &'a str {
    move || s
}

Isso indica que a closure retorna uma referência com a mesma lifetime do argumento.

Elisão de lifetimes: Rust permite omitir lifetimes em funções simples, mas em casos complexos, a elisão pode não se aplicar. Por exemplo, quando temos múltiplas entradas e uma saída, a elisão não é suficiente, e precisamos anotar.

fn primeiro_e_segundo<'a>(x: &'a str, y: &'a str) -> (&'a str, &'a str) {
    (x, y)
}

Entender esses casos ajuda a escrever código mais robusto e a depurar erros de empréstimo.

Referências

Exercícios

  1. Escreva uma struct Pessoa que armazena duas referências a str: nome e sobrenome. Crie uma instância e imprima o nome completo. Use lifetimes apropriadas.

    2. ✓ Resposta: 
    struct Pessoa<'a> {
    nome: &'a str,
    sobrenome: &'a str,
}

impl<'a> Pessoa<'a> {
    fn nome_completo(&self) -> String {
        format!("{} {}", self.nome, self.sobrenome)
    }
}

fn main() {
    let nome = String::from("Maria");
    let sobrenome = String::from("Silva");
    let pessoa = Pessoa { nome: &nome, sobrenome: &sobrenome };
    println!("{}", pessoa.nome_completo());
}
  2. Explique por que o código abaixo não compila e corrija-o usando Box::leak ou outra abordagem.
    3. fn retorna_ref() -> &'static str {
    let s = String::from("erro");
    &s
}

    ✓ Resposta:

    O código não compila porque s é uma String local que será destruída ao final da função, mas a referência é declarada como 'static, exigindo que viva para sempre. Para corrigir, podemos usar Box::leak para vazar a memória e obter uma referência estática:

    fn retorna_ref() -> &'static str {
    let s = String::from("erro");
    Box::leak(s.into_boxed_str())
}

    Isso faz com que a string viva por toda a duração do programa, mas a memória não será liberada, o que é aceitável em alguns casos.

  3. Defina uma função genérica maior que receba duas referências a tipos que implementam PartialOrd e retorne a maior delas. Use lifetime bounds.

    4. ✓ Resposta: 
    fn maior<'a, T: PartialOrd + 'a>(x: &'a T, y: &'a T) -> &'a T {
    if x > y { x } else { y }
}

fn main() {
    let a = 10;
    let b = 20;
    println!("{}", maior(&a, &b));
}
  4. Crie uma struct Wrapper que contenha uma referência a um tipo genérico T e implemente um método get que retorna a referência. Use lifetime bound T: 'a.

    5. ✓ Resposta: 
    struct Wrapper<'a, T: 'a> {
    valor: &'a T,
}

impl<'a, T> Wrapper<'a, T> {
    fn get(&self) -> &'a T {
        self.valor
    }
}

fn main() {
    let x = 42;
    let w = Wrapper { valor: &x };
    println!("{}", w.get());
}
  5. Considere o código abaixo. Ele compila? Se não, explique e corrija.
    6. fn retorna_par<'a>(x: &'a str, y: &'a str) -> (&'a str, &'a str) {
    (x, y)
}

fn main() {
    let a = String::from("oi");
    let b = String::from("tchau");
    let (r1, r2) = retorna_par(&a, &b);
    println!("{}", r1);
}

    ✓ Resposta:

    Sim, o código compila. A função retorna_par recebe duas referências com a mesma lifetime 'a e retorna ambas com a mesma lifetime. Como a e b vivem até o final do escopo de main, a lifetime 'a é o menor tempo de vida entre elas, que é o escopo de main. As referências retornadas são válidas enquanto a e b existirem, e são usadas dentro do escopo, então está correto.

Boas práticas e observações finais

Ao trabalhar com lifetimes, é importante manter o código legível. Use nomes de lifetime descritivos, como 'a, 'b, etc., em vez de nomes longos. Sempre que possível, deixe o compilador inferir lifetimes (elisão) em funções simples, mas em casos complexos, anote explicitamente para evitar ambiguidades.

Lembre-se de que lifetimes existem apenas em tempo de compilação; não há custo em tempo de execução. Aproveite o poder do sistema de tipos para garantir a segurança de memória sem sacrificar performance.

Finalmente, pratique! Escreva pequenos programas que forcem erros de lifetime e tente corrigi-los. Isso ajudará a internalizar as regras.