Rust 2018'de Non-Lexical Lifetimes (NLL)'nin istikrara kavuşmasından önce, derleyici borçlar için katı sözcüksel kapsamlar zorunlu tutuyordu; bu da vec.push(vec.len()) gibi ifadelerin yasadışı hale gelmesine neden oluyordu, zira push için gerekli olan değişken borç, len için gereken değişmez borçla çelişiyordu. Topluluk bu kısıtlamayı fazla ihtiyatlı buldu; çünkü değişken erişim aslında yöntem gövdesi çalışana kadar kullanılmıyordu ve bu da, değişmez incelemenin güvenli kaldığı teorik bir pencere yaratıyordu. Bu durum, değişken borcu rezervasyonu ile gerçek aktivasyonu ayırt eden iki aşamalı borçların tanıtılmasına yol açtı.
Temel zorluk, Rust'ın aliasing XOR değişiklik garantisini ergonomik API tasarımı ile birleştirmekte yatıyor; özellikle bir yöntem çağrısı &mut self gerektirirken, argümanlarının aynı nesne üzerinde &self gerektirmesi durumunda. Özel bir işleme olmadan, borç kontrolörü bu durumu ikinci değişken borç kuralının ihlali olarak işaretleyecek ve geliştiricilerin geçici değişkenlerle işlemleri manuel olarak sıralamasını zorunlu kılacaktır. Bu sorun, değişken istisnasını gerçek değişim noktasına kadar erteleyen ve ara değişmez erişimlerin geçişten veya asılı referanslar yaratmaktan önce sona ermesini sağlayan bir mekanizma gerektirmektedir.
İki aşamalı borçlar, bir yöntem çağrısındaki değişken borcu, argümanların değerlendirilmesi sırasında bir "rezervasyon" olarak ele alınarak, değerlendirme tamamlandıktan ve kontrol yöntem gövdesine girdiğinde "aktif hale getirilerek" çalışır. Rezervasyon aşamasında, derleyici sınırlı değişmez borçlara (özellikle alıcı üzerinde autoref'den türetilenler) izin verirken, bir değişken aktivasyonunun beklediğini izler. Bu, MIR (Orta Düzey Ara Temsil) borç kontrolü içinde uygulanır; burada derleyici, rezervasyon noktası ile aktivasyon noktası arasında çelişen kullanım olmadığını doğrulayarak güvenliği, çalıştırma zamanında enstrümantasyon yerine statik analiz yoluyla sağlar.
Bir ağ tampon yöneticisi düşünün; bu yönetici, iletim öncesinde paketleri toplamakla yükümlüdür. Sistem, geçerli tampon uzunluğuna bağlı olan bir başlık eklemelidir: buffer.append_header(buffer.current_len()). Burada, append_header, tamponu genişletmek için değişken erişim gerektirirken, current_len yalnızca değişmez inceleme gerektirir.
Geliştirici, değişimi gerçekleştirmeden önce uzunluğu ayrı bir bağlama çıkarabilir: let len = buffer.current_len(); buffer.append_header(len);. Bu yaklaşım tüm Rust sürümlerinde çalışır ve karmaşık borç kontrol kurallarından tamamen kaçınır. Ancak, bu, ayrıntılılık ekler ve kod, eşzamanlılık içerecek şekilde yeniden düzenlenirse, uzunluğun teorik olarak geçersiz hale gelme penceresi yaratır; fakat tek iş parçacıklı bağlamlarda bu tamamen stilde bir kaygıdır. Ana dezavantajı, ergonominin azalması ve geçici değişkenin gerekliliğini aşarak kapsamı karmaşıklaştırma potansiyelidir.
Tamponu bir RefCell içinde sarmak, hem çalışma zamanında hem de değişken borçlar sağlamak için borrow() ve borrow_mut() yöntemleri aracılığıyla mümkün olacaktır. Bu, derleme zamanı çatışmalarını giderir, kontrolleri çalışma zamanına ertelerken ve ihlal durumunda kapanmaya yol açabilir. Esnek olsa da, referans sayma ve çalışma zamanı doğrulama nedeniyle aşırı yük getirir; bu, yüksek verimlilikte ağ kodu için kritik olan sıfır maliyetli soyutlama ilkesini ihlal eder. Ayrıca, hataları derleme zamanı garantilerinden potansiyel çalışma zamanı hatalarına kaydırarak güvenilirliği azaltır.
Ekip, append_header'ı &mut self alan bir yöntem olarak yapılandırarak iki aşamalı borçları kullandı ve NLL borç kontrolörünün rezervasyonu otomatik olarak işlemesine güvendi. Bu, geçici değişkenler veya çalışma zamanı aşırı yük olmadan mantığın doğal olarak ifade edilmesini sağladı. Derleyici, current_len'in, değişken borç aktif hale gelmeden önce tamamlandığını doğruladı, böylece güvenliği sağladı. Bu çözüm, sıfır maliyetli soyutlamaları korurken, niyet edilen veri akışını doğru bir şekilde yansıtan temiz, bakımı kolay bir sözdizimini sağladığı için seçildi.
Uygulama, Rust 1.63+ üzerinde hatasız bir şekilde derlendi ve el ile sıralı koda eşdeğer optimal performans elde edildi. Tampon yöneticisi, tahsisat aşırı yük olmadan başarılı bir şekilde 10Gbps trafiğini işledi ve iki aşamalı borçların, ergonomi sorununu Rust'ın güvenlik garantilerini ihlal etmeden çözdüğünü gösterdi. Kod tabanı, içsel değişkenlik karmaşıklığından arındırılmış durumda kalarak, gelecekteki bellek güvenliği denetimlerini basitleştirdi.
İki aşamalı borç verme, açık dereference işlemleri ve operatör aşırı yüklemeleri ile nasıl etkileşir?
Birçok aday, iki aşamalı borçların tüm değişken referanslarına evrensel olarak uygulandığını varsayıyor; ancak bunlar özellikle yöntem çağrısı alıcılarında autoref durumları ile sınırlıdır. *vec gibi açık dereferencing yaptığında veya IndexMut gibi operatör özelliklerini kullanıldığında, borç kontrolörü iki aşamalı mantığı uygulamaz, hemen değişken borcu etkinleştirir. Bu kısıtlama, yöntem autoref'in (kapsama noktası) derleyicinin durum geçişlerini izleyebileceği açık bir rezervasyon noktası sağlamasından kaynaklanmaktadır; oysa keyfi dereference işlemleri bu anlamsal sınırı sağlamaz. Bu ayrımın anlaşılması, benzer görünümlü kodların derlenmediği durumlarda karışıklığı önler.
Derleyici, alıcının Drop uyguladığında iki aşamalı borç vermeyi neden yasaklar?
Adaylar genellikle, Drop uygulayan türlerin, rezervasyon aşamasını karmaşıklaştıran yok edici semantiklerinin olduğunu göz ardı eder. Yok edici çalışırken (örneğin, panik veya karmaşık kontrol akışı aracılığıyla) bir değişken rezervasyonu varsa, kısmen başlatılmış durum Drop'ın geçerli bir kendisine yönelik beklentilerini ihlal edebilir. Bu nedenle, derleyici özel yok edicilere sahip türlerde iki aşamalı borçları kısıtlar, yalnızca bunlar Copy değilse, değişken borcun aktivasyonunun drop glue işlemi ile çelişmeyebileceğini garanti eder. Bu, rezervasyon aşamasının, yığın açılırken kısmen taşınmış veya geçersiz bir durumu görmesini önleyen ince hatalardan kaçınır.
"Rezervasyon" aşaması ile "aktivasyon" aşaması, izin verilen işlemler açısından neyi ayırır?
Rezervasyon aşamasında, derleyici yalnızca yöntem çağrısının autoref'inden türetilen alıcının değişmez kullanımlarına izin verir, özel olarak argümanların değerlendirilmesini sağlar. Ancak, adaylar genellikle, arama değerlendirilmesi sırasında alıcıya ek adlandırılmış referanslar oluşturmanın veya başka işlevlere geçmenin yasak olduğunu gözden kaçırır. Aktivasyon aşaması, tam olarak kontrolün yöntem gövdesine girdiği anda başlar ve bu noktada argüman değerlendirmesinden yapılan tüm değişmez borçlar sona ermiş olmalıdır. Bu, katı bir doğrusal zaman çizelgesi oluşturur: rezervasyon → değişmez argüman değerlendirmesi → aktivasyon → yöntem çalıştırma. Bu sırayı ihlal etmek, örneğin bir referansı aktivasyon noktasından uzun ömürlü bir değişkende depolamak, münhasır garantileri korumak için derleme zamanı hatasına yol açar.