Rust: Variáveis e Imutabilidade

Definição do tipo

O Rust é uma linguagem de tipagem estática e forte. Em outras palavras, o compilador precisa conhecer o tipo de todas as variáveis no momento da compilação.

No entanto, você não precisa escrever o tipo em todo lugar. Quando a anotação não existe, o compilador infere o tipo a partir do valor e da forma como você usa a variável.

Na variável b, usamos o tipo u32, um inteiro sem sinal de 32 bits. Ou seja, ele ocupa 4 bytes e aceita apenas valores de 0 a 4.294.967.295.

Já nas variáveis a e c, não escrevemos o tipo. Se a aparecesse sozinha, o compilador escolheria i32, porque esse é o tipo inteiro padrão da linguagem.

Porém, a variável a participa de uma soma com b, que é u32. Por isso, a inferência conclui que a também é u32, e o resultado em c segue o mesmo tipo.

Esse comportamento mostra como a inferência considera o contexto inteiro, e não apenas o literal. Os tipos de dados merecem um estudo próprio, mas aqui o foco são realmente as variáveis no Rust.

As partes de uma declaração

De qualquer forma, podemos dividir uma declaração em quatro partes principais. Primeiro vem a palavra reservada, depois o nome, em seguida o tipo opcional e, por fim, o valor inicial.

keyword       variable type
   |               |
let <name>: <type> = <value>;
      |                 |
 variable name     initial value

Na prática, a anotação de tipo fica entre o nome e o sinal de igual, sempre precedida por dois pontos. Dessa forma, a leitura da linha segue a ordem natural: nome, tipo e valor.

Variáveis no Rust sem valor inicial

O valor inicial pode ficar para depois, desde que a variável receba um valor antes da primeira leitura. Nesse caso, o compilador acompanha todos os caminhos do código para garantir essa regra.

fn main() {
    let status;
    let is_active = true;

    // A variável recebe o valor uma única vez, em cada caminho
    if is_active {
        status = "active";
    } else {
        status = "inactive";
    }

    println!("Status: {}", status);
}

Repare que a variável status continua imutável, porque recebe o valor uma única vez. Por outro lado, se você tentar ler status antes da atribuição, o compilador recusa o código.

Essa regra elimina uma classe inteira de bugs comuns em outras linguagens, como a leitura de memória não inicializada. Com isso, as variáveis no Rust sempre têm um valor válido quando você as usa.

Por que forçar a imutabilidade

Uma variável é um espaço na memória ligado a um nome que reservamos no código. Com ela, reaproveitamos conteúdos, guardamos resultados e passamos dados entre partes do programa.

Se uma variável sofre uma mutação silenciosa no meio da execução, o programa pode falhar. De fato, boa parte dos bugs nasce exatamente de um valor que mudou quando ninguém esperava.

No mundo do .NET, temos conceitos como efeitos colaterais e o Open-Closed Principle, do SOLID, que buscam reduzir esse risco. Da mesma forma, o C# trata strings como imutáveis para evitar alterações inesperadas.

O Rust foi além, porque tornou a imutabilidade o comportamento padrão. Assim, o primeiro valor atribuído permanece até o fim do escopo, a menos que você peça o contrário de forma explícita.

Segundo a documentação oficial do Rust, essa escolha evita que uma parte do código altere um valor que outra parte considera fixo. Em suma, o compilador garante que o valor não muda, e você não precisa rastrear isso de cabeça.

Por consequência, as variáveis no Rust tornam o código mais fácil de entender. Quando você lê um let sem mut, já sabe que aquele valor não vai mudar em lugar nenhum.

Imutabilidade e threads

A imutabilidade é um dos pilares que tornam o Rust seguro, principalmente em código concorrente. Para entender isso, imagine duas threads que compartilham uma variável.

Vamos criar um cenário em que as duas tentam incrementar o mesmo contador. Nesse caso, a consistência dos dados depende de quem altera o valor e quando.

use std::thread;

fn main() {
    // Criamos uma variável imutável chamada "counter"
    let counter = 0;

    // Criamos duas threads que tentam incrementar o contador
    let thread1 = thread::spawn(|| {
        for _ in 0..1000 {
            // Tentativa de incrementar o contador
            // Isso resulta em um erro de compilação!
            counter += 1;
        }
    });

    let thread2 = thread::spawn(|| {
        for _ in 0..1000 {
            // Tentativa de incrementar o contador
            // Isso também resulta em um erro de compilação!
            counter += 1;
        }
    });

    // Aguardamos a conclusão das threads
    thread1.join().unwrap();
    thread2.join().unwrap();

    // Exibimos o valor final do contador
    println!("Final counter value: {}", counter);
}

Nesse exemplo, criamos uma variável imutável chamada counter. Em seguida, duas threads tentam incrementar o mesmo valor em paralelo.

No entanto, o compilador impede a operação, pois a variável é imutável. Portanto, o programa nem chega a rodar.

Em outras linguagens, bastaria tornar o contador mutável para cair em uma condição de corrida, com resultados diferentes a cada execução. No Rust, adicionar mut não resolve, porque o compilador também recusa duas threads com acesso mutável ao mesmo valor.

Em outras palavras, o sistema de ownership e borrowing barra o problema antes da execução. Se você usar move nas closures, cada thread recebe uma cópia do inteiro, e o contador original continua valendo zero.

Para compartilhar um valor mutável entre threads, o Rust pede ferramentas próprias. A solução clássica combina Arc, que conta referências de forma atômica, com Mutex, que garante acesso exclusivo.

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    // Arc permite compartilhar o valor; Mutex controla o acesso
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..2 {
        let counter = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            for _ in 0..1000 {
                // lock() garante que só uma thread altera o valor por vez
                let mut num = counter.lock().unwrap();
                *num += 1;
            }
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    // Sempre exibe 2000
    println!("Final counter value: {}", *counter.lock().unwrap());
}

Repare que a variável counter continua imutável, mas o Mutex libera a alteração de forma controlada. Dessa forma, a mutação existe, porém sempre com regras claras e verificadas.

Se você trabalha com C#, a ideia lembra o uso de travas e semáforos, como mostra o artigo sobre Semaphore e SemaphoreSlim. A diferença é que, no Rust, o compilador cobra essa disciplina.

Onde colocar o mut

Agora vem a questão: onde você adicionaria o mut? Nas variáveis do main ou nos parâmetros da função?

A resposta correta é nos parâmetros. Isso mesmo, quando a função precisa modificar um parâmetro, ele também recebe o mut.

fn increment_and_sum(mut x: u32, mut y: u32) -> u32 {
    x += 1;
    y += 1;
    return x + y;
}

Isso acontece porque os parâmetros recebem uma cópia dos valores a e b, já que inteiros implementam a trait Copy. Portanto, as variáveis do main continuam imutáveis e não mudam depois da chamada.

Também vale notar que o return explícito é opcional. Em código idiomático, a última expressão da função, sem ponto e vírgula, já define o retorno.

Shadowing e escopo

O shadowing respeita os blocos de código. Quando você faz sombra dentro de um bloco interno, a variável externa volta a valer assim que o bloco termina.

fn main() {
    let x = 5;
    let x = x + 1;
    {
        // Esta sombra vale apenas dentro do bloco
        let x = x * 2;
        println!("The value of x in the inner scope is: {x}");
    }
    println!("The value of x is: {x}");
}

// The value of x in the inner scope is: 12
// The value of x is: 6

Nesse exemplo, o bloco interno enxerga o valor 12. Contudo, depois das chaves, o x externo continua valendo 6.

Shadowing não é o mesmo que mut

Shadowing não equivale a tornar uma variável mutável. Com shadowing, você cria uma nova variável, e isso permite inclusive trocar o tipo do valor.

fn main() {
    let x: u32 = 5;
    let x = String::from("Hello, world!");
    println!("The value of x is: {}", x);
}

// The value of x is: Hello, world!

Se você tentar o mesmo com mut, o compilador recusa. Afinal, uma variável mutável aceita outro valor, mas sempre do mesmo tipo.

fn main() {
    let mut spaces = "   ";
    // error[E0308]: mismatched types
    spaces = spaces.len();
}

Além disso, o shadowing exige um novo let. Por isso, uma atribuição acidental sem let continua gerando erro de compilação, e a variável segue imutável depois das transformações.

O shadowing também permite reaproveitar nomes em vez de inventar variações como spaces_str e spaces_num. Dessa forma, você transforma valores sem torná-los mutáveis e converte tipos quando necessário.

Pode parecer estranho no começo. Porém, quando você estudar borrowing e ownership, vai perceber que esse conceito se encaixa muito bem no restante da linguagem.