Soru Tarihçesi: Rust'ın erken sürümleri, açık yok edici çağrılar gerektiriyordu. Drop traitinin tanıtılması, kaynak temizliği işlemini otomatikleştirmiş ancak Rust'ın taşıma semantiklerinin birleşiminde karmaşıklık getirmiştir. Kısmi taşınma problemi—bazı alanların bir yapıdan taşınması ve diğerlerinin kalması—, serbest kullanım veya çifte düşme hatalarını önlemek için düşme sırasının dikkatlice tanımlanmasını gerektiriyordu. Dil tasarımcıları, özel Drop uygulamasının bu senaryoda çalışıp çalışmayacağını belirlemek zorundaydılar.
Problem: Bir yapı Drop uyguladığında, derleyici yok edicinin, güvenlik değişmezliklerini korumak için tüm alanlara erişim gerektirdiğini varsayar (örneğin bir Mutex'in kilidini açmak veya belleği serbest bırakmak için). Eğer bir desen eşleştirmesi sadece bazı alanları taşırsa (let Foo { a, .. } = foo), kalan alanların yok edilmesi gerekecektir, ancak özel Drop uygulaması taşınan alanlara erişebilir, bu da tanımsız bir davranışa yol açabilir. Bu, programcının veri çıkarmak isteği ile yok edicisinin iç duruma tam erişimle çalışacağı garantisi arasındaki bir çatışma yaratır.
Çözüm: Derleyici, Drop uygulayan bir yapıdan alanların kısmi taşınmasını yasaklar, aksi takdirde yapı, desende tamamen de yapılandırılmadığı sürece (tüm alanları bağlayarak) taşınmış olarak kabul edilir ve Drop çağrılmaz; bunun yerine, bireysel alanlar tanım sırası tersine düşer. Drop olmayan türler için kısmi taşınmalara izin verilir çünkü derleyici tarafından oluşturulan düşme kodu sadece kalan alanlara dokunur.
struct NoDrop(String, i32); struct WithDrop(String, i32); impl Drop for WithDrop { fn drop(&mut self) { println!("Düşürülüyor: {}", self.0); } } fn main() { let no_drop = NoDrop("a".into(), 1); let NoDrop(s, _) = no_drop; // TAMAM: kısmi taşınmaya izin verildi // println!("{}", no_drop.0); // HATA: değer taşındı println!("Kalan: {}", no_drop.1); // TAMAM: alan 1 hâlâ geçerli drop(s); let with_drop = WithDrop("b".into(), 2); // let WithDrop(s, _) = with_drop; // HATA: Drop uygulayan türden kısmi taşınma yapılamaz let WithDrop(s, n) = with_drop; // TAMAM: toplam yok etme, Drop çağrılmaz println!("Taşıdı: {} ve {}", s, n); // Alanlar, kapsamın sonunda bireysel olarak düşürülür. }
Bir sistem programlama ekibi, Zero-Copy ağ paket analizörü inşa etti. Bir ham belleğe ve birkaç meta veri alanına (zaman damgası, uzunluk) referans tutan bir Packet yapısı tanımladılar. Packet, belleği havuza geri döndürmek için Drop uyguladı. Paket işlenirken loglama için sadece zaman damgasını çıkarmaya çalıştılar ve bir eşleşme kolunda kısmi taşınma kullandılar.
Çözüm 1: Drop uygulamasını kaldırın ve havuzu yöneten ayrı bir PacketHandle sarmalayıcı kullanın; bu durumda Packet, düşme mantığı olmayan düz bir görüntü hâline gelir. Artılar: Bu, Packet alanlarının kısmi taşınmasına izin verir ve kaynak yönetimini veri erişiminden açıkça ayırır. Eksiler: Ek bir dolaylı katman getirilir ve görünümün bellekten uzun ömürlü olmamasını sağlamak için dikkatli yaşam süresi yönetimi gerektirir; yanlış yönetilirse güvenliği tehlikeye atabilir.
Çözüm 2: Kısmi taşınmayı önlemek için taşınmadan önce zaman damgası alanını kopyalayın. Artılar: Bu, mevcut yapıyı asgari kod değişikliği ile koruyan basit bir değişikliktir. Eksiler: Klonlama için çalışma zamanı maliyeti oluşur; tam sayılar için önemsiz olsa da, karmaşık meta veriler için önemli hale gelir ve tür sisteminin temel mimari kısıtlamasını ele almaz.
Çözüm 3: İşlem işlevini, tüm Packet'in sahipliğini alacak şekilde yapılandırın, alanları toplam yok etme yoluyla çıkarın ve havuz dönüşü için gerekirse yeni bir Packet yeniden oluşturun. Artılar: Bu, Rust'ın güvenlik garantileriyle sıkı bir şekilde çalışır ve sahiplik devrini açık hale getirir. Eksiler: Bu, ayrıntılıdır ve belleğin doğru bir şekilde geri döndürüldüğünü sağlamak için dikkatli bir işlem gerektirir; düzgün oluşturulmadığında kaynak sızıntılarına yol açabilir.
Ekip, kaynakları (belleği) görünümden (meta veriler) ayırarak Rust'ın sahiplik modeliyle temelde uyumlu olduğu için Çözüm 1'i seçti. Bu, derleme hatalarını derhal ortadan kaldırdı, kaynak yönetimi ve veri görünümündeki ayrımı netleştirerek kodun açıklığını artırdı ve projenin sıfır maliyetli soyutlama gereksinimlerini korudu.
Neden derleyici, Drop uygulayan türlerde kısmi taşınmayı yasaklar?
Bir tür Drop uyguladığında, derleyici kapsamın sonunda drop() çağrısı üretir. drop() metodu &mut self alır ve bu da tam yapı üzerinde erişim gerektirdiğini ima eder; bu, kilitlerin serbest bırakılması veya belleğin serbest bırakılması gibi güvenlik değişmezliklerini korumak için. Eğer bir alan daha önce kısmi taşınma yoluyla taşınırsa, drop() serbest bırakılmış belleği veya geçersiz kaynakları erişmeye çalışabilir ve bu da tanımsız bir davranışa yol açar. Tüm alanların bağlanmasını gerektirerek, Rust yok edici kodun asla çalıştırılmadığından emin olur; bunun yerine, alanlar bireysel olarak düşürülerek potansiyel olarak tehlikeli özel mantığı atlatılır.
Bir yapı desen eşleştirmesi ile tamamen yok edildiğinde tam düşme sırası nedir?
Bir yapı tamamen yapılandırıldığında (örneğin, let MyStruct { field1, field2 } = my_struct;), yapının Drop uygulaması tamamen bastırılır. Alanlar, yapı tanımındaki bildirim sırasının tersine düşürülür (field2 ardından field1 bu durumda). Bu davranış, yapı alanlarının standart düşme sırasıyla eşleşir, ancak kritik olarak aşırı durumu atlayarak, taşınmış durumu gözlemleme ve güvenlik garantilerini ihlal etme olasılığı doğurur.
Drop ile bir tür, yok ediciyi idempotent hale getirirsek, Copy olabilir mi?
Hayır, Rust derleyicisi Copy ve Drop'un, yok edicinin gerçek uygulamasına bakılmaksızın, trait uyum kuralları aracılığıyla karşıt olduğunu zorunlu kılar. Bu, kasıtlı olarak temkinli bir tasarım seçeneğidir: drop() şu anda boş veya idempotent olsa bile, Copy'ye izin vermek, örtük bit düzeyinde çoğaltmayı sağlardı. Gelecek değişiklikler drop()'ı idempotent olmayan hale getirebilir, güvenlik garantilerini gizlice ihlal edebilir ve derleyici derleme zamanında genelde idempotansı doğrulamadığı için, geçersizliği önlemek üzere bu kombinasyonu açıkça yasaklar.