Ownership & Borrowing
Borrow checker'ı anlamak

00 Neden ownership?

C bellek hatalarını çalışma zamanına bırakır, GC ise runtime maliyet ekler — Rust üçüncü yolu seçer: derleme-zamanı sahiplik.

Bir C/C++ programcısı olarak bellek hatalarının taksonomisini ezbere biliyorsundur: use-after-free (serbest bırakılmış belleğe erişim), double-free (aynı bloğu iki kez serbest bırakma), memory leak (hiç bırakmama) ve dangling pointer (ömrü bitmiş nesneye işaret eden pointer). Bu hataların ortak özelliği: derleyici sessizdir, sorun çalışma zamanında — çoğu zaman üretimde — patlar. Valgrind, ASan ve code review bunları azaltır ama matematiksel bir garanti vermez.

Geleneksel olarak iki çözüm vardı. Birincisi manuel yönetim (C/C++): hızlı ve deterministik, ama güvenliği programcının disiplinine bırakır. İkincisi garbage collection (Java, Go, C#): güvenli, ama runtime'da tarama döngüleri, durdur-dünya (stop-the-world) duraklamaları ve öngörülemez gecikme getirir — gömülü ve gerçek-zamanlı sistemlerde kabul edilemez.

Rust üçüncü yolu seçer: belleği derleme zamanında bir sahiplik (ownership) modeliyle yönetir. Çalışma zamanında GC yoktur, ekstra metadata yoktur; kontroller derleyicide yapılır ve geçen kod sıfır-maliyet (zero-cost) çalışır. Aşağıdaki C örneği klasik bir use-after-free içerir — Rust'ta karşılığı derlenmez bile.

// C: derleyici hiçbir şikayet etmez, runtime'da UB.
char *p = malloc(16);
strcpy(p, "merhaba");
free(p);
printf("%s\n", p);   // use-after-free — patlayabilir, patlamayabilir

fn main() {
    let s = String::from("merhaba");
    drop(s);             // belleği elle bıraktık (genelde gerek yok)
    println!("{s}");     // HATA: borrow of moved value: `s`
}
// error[E0382]: derleyici durdurur; runtime UB asla oluşmaz.

01 Ownership kuralları

Tüm modelin üç kurala indiği nokta — bunları içselleştirince borrow checker artık düşman değil refleks olur.

Rust'ın bütün bellek modeli üç basit aksiyoma dayanır:

Üçüncü kural bir C++ programcısına RAII gibi gelmeli — çünkü tam olarak öyle. Fark şu: C++'ta RAII bir kütüphane deseni ve programcı disiplinidir; Rust'ta dilin değişmez kuralıdır ve sahiplik takibi derleyici tarafından zorlanır.

Stack vs heap: nerede yaşar?

Sabit boyutlu ve Copy olan değerler (i32, bool, char) stack'te yaşar; ucuz kopyalanır. String ise üç alandan oluşan bir fat değerdir: stack'te bir başlık (heap'e pointer + uzunluk + kapasite), asıl bayt verisi heap'te. Sahip scope'tan çıkınca heap belleği String'in Drop implementasyonu tarafından serbest bırakılır.

fn main() {
    let n = 42;                       // stack: i32, Copy
    {
        let s = String::from("selam"); // başlık stack'te, "selam" heap'te
        println!("{s} / {n}");
    } // s burada scope'tan çıktı -> String::drop çağrıldı, heap free

    println!("{n}"); // n hâlâ geçerli; s artık yok
}

let s = String::from(...)  →  scope sonu  →  drop(s)  →  heap free

02 Move semantiği

Rust'ta varsayılan atama move'dur, kopya değil — ve move sonrası kaynak değişken kullanılamaz hale gelir.

C++'ta auto b = a; varsayılan olarak kopyalar (copy constructor); taşımak istersen açıkça std::move(a) yazarsın. Rust tam tersini yapar: non-Copy tipler için varsayılan atama move'dur. Move sırasında stack başlığı bit-bit yeni değişkene aktarılır ve eski değişken geçersizleştirilir. Heap verisi kopyalanmaz — yalnızca tek geçerli sahip vardır (Kural 2).

fn main() {
    let a = String::from("veri");
    let b = a;            // MOVE: başlık a'dan b'ye taşındı, a artık geçersiz

    println!("{b}");     // OK
    println!("{a}");     // HATA[E0382]: borrow of moved value: `a`
}

Bu neden hatadır? Çünkü ikisi de geçerli kalsaydı, ikisi de aynı heap bloğunu işaret eder, ikisi de scope sonunda drop çalıştırır — klasik double-free. Rust kaynağı move ile geçersizleştirerek bu durumu kökünden imkânsız kılar. C++'ın "moved-from" nesnesi geçerli-ama-belirsiz durumdadır; Rust'ta moved-from değer derleyici tarafından kullanılamaz ilan edilir.

Fonksiyona move

Bir değeri fonksiyona değer olarak (by value) geçirmek de move'dur. Çağrıdan sonra kaynak değişken artık senin değildir.

fn yut(s: String) {
    println!("yutuldu: {s}");
} // s burada drop edilir

fn main() {
    let t = String::from("merhaba");
    yut(t);              // t fonksiyona MOVE edildi
    // println!("{t}");  // HATA: t artık geçersiz
}

03 Copy vs Clone

Bazı tipler move yerine sessizce kopyalanır (Copy); derin kopya istiyorsan açıkça .clone() dersin.

Her tip move semantiğine uymaz. Sabit boyutlu, tamamen stack'te yaşayan ve "bitlerini kopyalamak yeterli" olan tipler Copy trait'ini implement eder: i32, u64, bool, char, f64, ve yalnızca Copy alanlardan oluşan tuple/struct'lar. Bunlarda let b = a; kaynağı geçersizleştirmez — çünkü ucuz bir bit kopyası yapılır ve iki bağımsız değer ortaya çıkar, double-free riski yoktur.

fn main() {
    let x = 5;
    let y = x;        // COPY: i32 Copy'dir, x hâlâ geçerli
    println!("{x} {y}");  // OK -> 5 5
}

Clone: açık ve potansiyel pahalı

String, Vec<T>, HashMap gibi heap sahibi tipler Copy değildir; çünkü ucuz bit kopyası iki sahip yaratır. Gerçek bir derin kopya istiyorsan .clone() çağırırsın — bu, heap verisini yeni bir blok olarak çoğaltır. Çağrı açıktır: kodda .clone() görmek "burada heap tahsisi/kopyası var" demektir.

fn main() {
    let a = String::from("veri");
    let b = a.clone();   // DERİN kopya: yeni heap bloğu, ayrı veri

    println!("{a} | {b}");  // her ikisi de geçerli -> veri | veri
}

04 Sahipliği fonksiyonlarla taşımak

Sadece move ile çalışmak değeri fonksiyonlara "ver-geri al" döngüsüne sokar — bu hantallık borrowing'in doğuş sebebidir.

Move semantiği tutarlıdır ama saf haliyle kullanışsızdır. Bir String'i bir fonksiyona verip sonra ana fonksiyonda kullanmaya devam etmek istersen, fonksiyonun onu geri döndürmesi gerekir. Tek bir veri için bu katlanılabilir; ama hem değeri kullanıp hem de bir sonuç döndürmek istediğinde tuple iadelerine boğulursun.

// Borrowing yokken: sahipliği al, geri döndür — hantal.
fn uzunluk(s: String) -> (String, usize) {
    let n = s.len();
    (s, n)              // sahipliği çağırana geri verebilmek için s'i iade et
}

fn main() {
    let s = String::from("merhaba");
    let (s, n) = uzunluk(s); // move ettik, geri aldık... yorucu
    println!("'{s}' uzunluğu {n}");
}

Buradaki hantallık tesadüf değil — Rust seni doğal olarak doğru araca itiyor. İhtiyacın olan şey değeri sahiplenmeden, sadece geçici olarak okumak/değiştirmek. Bu da borrowing (ödünç alma): sahibi değiştirmeden bir referans (reference) ödünç vermek.

move-and-return (hantal)  →  borrow &T / &mut T (zarif)

// Borrowing ile: sahiplik s'te kalır, sadece referans veririz.
fn uzunluk(s: &String) -> usize {
    s.len()             // okuruz ama sahiplenmeyiz
}

fn main() {
    let s = String::from("merhaba");
    let n = uzunluk(&s);  // & ile ödünç verdik
    println!("'{s}' uzunluğu {n}"); // s hâlâ bizim
}

05 Borrowing — &T

Paylaşımlı referans &T: veriyi sahiplenmeden okumana izin verir, aynı anda istediğin kadar olabilir.

&T bir paylaşımlı (shared), değiştirilemez (immutable) referanstır. C'deki const T* ile kavramsal olarak benzer ama kritik bir farkla: Rust'ta referansın işaret ettiği değerin &T yaşadığı sürece geçerli kalacağı (dangling olmayacağı) derleyici tarafından garanti edilir. Bir referans, ödünç verenden daha uzun yaşayamaz.

Aynı veriye aynı anda istediğin kadar &T alabilirsin — okuyucular birbirini rahatsız etmez. Hiçbiri veriyi değiştiremediği için bu güvenlidir.

fn main() {
    let s = String::from("merhaba");

    let r1 = &s;      // paylaşımlı borrow
    let r2 = &s;      // ikinci paylaşımlı borrow — sorun yok

    println!("{r1} ve {r2} ve {s}"); // üçü de okuyabilir
}

Referansları dereference etmek için * kullanılır, ama method çağrıları ve çoğu operatör otomatik dereference (auto-deref) yaptığı için çoğu zaman * yazmazsın:

fn topla(v: &Vec<i32>) -> i32 {
    let mut acc = 0;
    for x in v {       // &Vec üzerinde iter; x: &i32
        acc += *x;       // *x ile i32 değerine eriş
    }
    acc
}

06 &mut T — değiştirilebilir ödünç

Değiştirilebilir referans &mut T veriyi değiştirmene izin verir — ama aynı anda tek tane olabilir.

&mut T ile ödünç aldığın veriyi değiştirebilirsin. Kritik kısıt şudur: bir değer için aynı anda yalnızca bir &mut var olabilir ve bir &mut aktifken aynı veriye başka hiçbir referans (ne & ne &mut) olamaz. Üstelik veriyi &mut ile ödünç verebilmek için değişkenin de mut olması gerekir.

fn ekle(s: &mut String) {
    s.push_str(" dünya");   // &mut üzerinden mutasyon serbest
}

fn main() {
    let mut s = String::from("merhaba"); // mut: değişebilir
    ekle(&mut s);
    println!("{s}");     // -> merhaba dünya
}

Tek &mut kuralı neden var?

Cevap: veri yarışını (data race) derleme zamanında imkânsız kılmak. Bir veri yarışı, en az iki erişim aynı belleğe ulaşırken en az biri yazma yapıyor ve erişimler senkronize değilse oluşur. Eğer aynı anda hem bir yazıcı (&mut) hem de başka bir okuyucu/yazıcı olsaydı, klasik data race elimizde olurdu. Rust bunu tip sisteminde yasaklar.

fn main() {
    let mut s = String::from("x");

    let r1 = &mut s;
    let r2 = &mut s;   // HATA[E0499]: ikinci &mut, aynı anda olamaz

    println!("{r1} {r2}");
}

07 Borrow checker kuralları

Tüm borrow sistemi tek ilkeye iner: aliasing XOR mutation — ya çok okuyucu, ya tek yazıcı; ikisi birden asla.

Önceki iki bölümün özeti tek bir invariant'tır. Herhangi bir an için, bir veriye ya:

çok sayıda &T (okuyucu)   XOR   tam bir tane &mut T (yazıcı)

Aynı anda hem paylaşımlı okuyucular hem de bir yazıcı olamaz. Bu "aliasing XOR mutability" ilkesi, hem veri yarışlarını hem de bellek bozulmasını (memory corruption) statik olarak engelleyen tek kuraldır. Borrow checker dediğimiz derleyici aşaması tam olarak bunu kontrol eder.

NLL: referanslar son kullanımda biter

Erken Rust'ta bir referans, içinde tanımlandığı blok bitene kadar "canlı" sayılırdı. Bugün Non-Lexical Lifetimes (NLL) sayesinde bir borrow, son kullanıldığı satırda sona erer — kapanış parantezinde değil. Bu sayede aşağıdaki kod derlenir:

fn main() {
    let mut s = String::from("x");

    let r = &s;          // paylaşımlı borrow başlar
    println!("{r}");     // r'nin SON kullanımı -> borrow burada biter (NLL)

    let m = &mut s;      // OK: artık aktif paylaşımlı borrow yok
    m.push_str("y");
    println!("{m}");
}

Tipik hata ve düzeltmesi

En sık görülen ihlal: bir okuyucu hâlâ canlıyken yazmaya kalkmak. Aşağıda hata ve iki düzeltme yolu:

fn main() {
    let mut v = vec![1, 2, 3];

    let ilk = &v[0];     // paylaşımlı borrow, ilk hâlâ canlı
    v.push(4);           // HATA[E0502]: v'yi &mut almaya çalışır; ilk borrow aktif
    println!("{ilk}");   // ilk'in kullanımı borrow'u canlı tutuyor
}

// DÜZELTME: ilk'i push'tan ÖNCE kullanıp bitir (NLL),
// ya da değeri kopyala: let ilk = v[0]; (i32 Copy).

08 Slice'lar — &[T] ve &str

Slice, sahiplik almadan bir koleksiyonun bitişik bir parçasına açılan ödünç pencere — ptr + uzunluktan ibaret.

Bir slice (dilim), bir koleksiyonun bitişik (contiguous) bir aralığına ödünç verilmiş görünümdür. Sahiplik almaz; içinde sadece bir pointer ve bir uzunluk taşır (fat pointer). C'deki "pointer + length" idiomunun tip-güvenli, sınır-takipli halidir. İki temel slice tipi vardır:

fn main() {
    let s = String::from("merhaba dünya");
    let ilk: &str = &s[0..7];   // "merhaba" — sahiplik yok, ödünç

    let v = vec![10, 20, 30, 40];
    let orta: &[i32] = &v[1..3]; // [20, 30]

    println!("{ilk} / {orta:?}");
}

Parametre tipi: neden &str ve &[T]?

Bir fonksiyon parametresinde &String yerine &str, &Vec<T> yerine &[T] almak en iyi pratiktir. Sebep: slice daha geneldir. &str alan bir fonksiyon hem String (deref ile) hem string literal hem alt-dilim kabul eder; tek bir imza her kaynağa uyar.

// İYİ: &str daha esnek — String, literal, dilim hepsi geçer.
fn ilk_kelime(s: &str) -> &str {
    match s.find(' ') {
        Some(i) => &s[..i],
        None    => s,
    }
}

fn main() {
    let sahip = String::from("merhaba dünya");
    println!("{}", ilk_kelime(&sahip));     // String -> &str (deref coercion)
    println!("{}", ilk_kelime("selam ck"));  // literal zaten &str
}

09 Drop, RAII ve sık hatalar

Drop trait'i Rust'ın RAII'sidir — C++ destructor'ının birebir karşılığı, ama move sayesinde double-drop garantili imkânsız.

Bir tip scope'tan çıkarken kaynak bırakması gerekiyorsa Drop trait'ini implement eder. Bu, C++ destructor'ının doğrudan karşılığıdır: dosya kapatma, soket bırakma, kilit çözme gibi temizlikler burada yapılır. String, Vec, File, MutexGuard hepsinin bir Drop'u vardır ve derleyici çağrıyı scope sonuna otomatik yerleştirir.

struct Kaynak {
    ad: String,
}

impl Drop for Kaynak {
    fn drop(&mut self) {       // C++ ~Kaynak() gibi
        println!("bırakılıyor: {}", self.ad);
    }
}

fn main() {
    let _a = Kaynak { ad: String::from("A") };
    {
        let _b = Kaynak { ad: String::from("B") };
    } // -> "bırakılıyor: B"  (ters sırada, B önce)
} // -> "bırakılıyor: A"

C++'ta unique_ptr taşındığında kaynak nesne null'a set edilir ki yıkıcı iki kez free yapmasın. Rust'ta bu davranış dile gömülüdür: bir değer move edildiğinde derleyici eski sahibin drop'unu çalıştırmaz; yalnızca son geçerli sahip drop edilir. Böylece double-drop tasarımdan imkânsızdır — programcı disiplinine değil, sahiplik kurallarına dayanır.

En sık 3 borrow checker hatası — oku ve çöz