Cevap.

Sorunun Tarihi

Desen eşleştirme, Rust'ta en önemli dil mekanizmalarından biridir ve fonksiyonel dillerden gelmektedir. Karmaşık değerlerin varyasyonlarını açıklayıcı, özlü ve güvenli bir şekilde analiz etmeyi sağlar, bunun yanı sıra ek koşullarla (guard ifadeleri) birlikte kullanılabilir, bu da esneklik ve kontrol sağlar.

Problem

Exhaustiveness checking (tüm variantlerin kapsamlı incelemesi) olmadan, desen eşleştirmenin gücünün bazı senaryoları hatalarla gerçekleştirilebilir. Ayrıca, dal sırasını ve guard ifadelerini anlamadan, ya mantıkta ya da performansta hata yapılabilir.

Çözüm

Rust'ta, derleyici tüm enum varyantlarının (veya daha basit desen yapıların) incelendiğini veya bir _ dalının bulunduğunu kontrol eder. Dal, guard ifadesi (if desenin ardından) ile ek olarak kısıtlanabilir ve yalnızca koşul gerçekleştirilirse "tetiklenir". Kalan varyantlar — yakalanmaz. Dal sırası önemlidir: yukarıdan aşağıya kontrol edilir.

Kod örneği:

enum Mesaj {
    Merhaba,
    Veri(i32),
    Çıkış,
}

fn işle(handle: Mesaj) -> &'static str {
    eşleştir(msg) {
        Veri(n) if n > 10 => "Büyük Veri",
        Veri(_) => "Bazı Veriler",
        Merhaba => "Selam!",
        Çıkış => "Hoşça kal",
    }
}

Ana özellikler:

Exhaustiveness checking sayesinde güvenlik: derleyici durumların atlanmasına izin vermez (veya kesinlikle '_' koymaya zorlar).
İşlemeyi genişletmek için guard kullanma imkanı.
Dallar yukarıdan aşağıya kontrol edilir, ilk eşleşen desen+guard tetiklenir.

Kapalı Sorular.

Eğer desen eşleşirse ama koşul gerçekleşmezse, guard ile dal tetiklenir mi?

Hayır, bu durumda kontrol bir sonraki uygun dala geçer. Desen + guard — atomik bir "filtre"; yalnızca her ikisi de eşleştiğinde dalın gövdesi çalışır.

Match içindeki dal sırası performansı etkiler mi?

Evet. Özellikle benzer patternerin çok olduğu durumlarda: derleyici dalları yukarıdan aşağıya kontrol eder, bu da çalışma zamanında kontrol hızını etkiler — daha sık karşılaşılan değerlerin önce işlenmesi gerekir.

Sadece _ dalı koyarak exhaustiveness checking'i atlamak mümkün mü?

Teknik olarak evet — bu mümkündür, ancak güvenilirlik kaybolur: eğer tip yeni elemanları eklerse (veya çıkarırsa), derleyici ele alınmamış bir durum hakkında uyarı vermez. Her zaman önemli olanları açıkça işlemek daha iyidir, '_' ise yalnızca zorunlu durumlarda kullanılmalıdır.

Tipik Hatalar ve Antipatiler

Koşul geçmediğinde desenin "eşleştiğini" düşünerek guard kullanımı: göz önünde olmayan durumlar.
Belirsiz desenlerde dal sırasının göz ardı edilmesi, yanlış mantık.
Enumu her zaman kapsamlı bir şekilde ele almak, her şeyi "_" içinde boğmamak gerekir.

Gerçek Hayat Örneği

Olumsuz Durum

Guard ifadeleri olan enum için bir match kodu, burada guard ile desen en son geliyor, ancak çoğu değer önceki _ dalından doğrudan geçiyor ve gerekli işleme asla ulaşmıyor.

Artılar:

_ şeklinde hızlı bir "geçici" uygulama.

Eksiler:

Mantık çalışmıyor, gerekli değerler yakalanmıyor ve kodu test etmek zor.

Olumlu Durum

Önce en yaygın ve önemli varyantlar (guard ile) listelenir, ardından geri kalanlar kapsamlı bir şekilde ele alınır — _ içinde gereksiz kod olmadan.