Tarih, Haskell (ihtiyaç bazında çağrı) ve Scala (isim bazında çağrı) gibi işlevsel programlama dillerine kadar uzanır. Tembel değerlendirme, gereksiz hesaplamaları önler. Swift, temiz bir sözdizimini, doğrulamalar ve kontrol akışı operatörleri (&&, ||) ile sağlarken performanstan ödün vermemek için bu modeli benimsemiştir. Sorun, argümanların hesaplanmasının maliyetli veya yan etkileri olduğunda ortaya çıkar; ancak istekli değerlendirme, gereklilikten bağımsız olarak yürütülmeye zorlar.
Derleyici, çağrı yerini, argüman ifadesini içeren bir sıfır-argüman kapanışı { expression } içerisine otomatik olarak sararak dönüştürür. Bu kapanış (thunk), hesaplanan sonuç yerine işlevine iletilir. İşlev gövdesi parametreye eriştiğinde, kapanışı çağırarak değerlendirmeyi o anda tetikler. ARC ile ilgili olarak, sentezlenmiş kapanış, dış kapsamdan değişkenleri referansla yakalar; eğer autoclosure @escaping olarak işaretlenirse, kapanış bağlamını heap'te tahsis eder, herhangi bir yakalanan referans türünü tutar ve bunların yaşam süresini orijinal kapsamın ötesine uzatabilir.
Ağ yüksek frekansı ticareti analitik kontrol paneli geliştirirken, hata ayıklama günlük dizgelerinin piyasa veri nesnelerinin ağır JSON serileştirmesini gerektirdiğini düşünün. Sorun, üretim yapılarının hata ayıklama günlüklerini devre dışı bırakmasıydı, ancak dize interpolasyonu log("Data: \(heavyObject.serialize())") her piyasa tikinde yürütülüyordu ve gereksiz yere %30 CPU tüketiyordu.
Bir çözüm, açık bir son kapanış geçirmeyi içeriyordu: log { "Data: \(heavyObject.serialize())" }. Bu ertelemeyi mükemmel bir şekilde sağladı, ancak söz dizimi kod tabanını yüzlerce süslü parantezle kalabalıklaştırarak okunabilirliği azalttı ve grep aramalarını zorlaştırdı. Geliştiriciler de bazen kapanış sözdizimini unuttu ve yanlışlıkla istekli değerlendirmeye geri döndüler.
Diğer bir yaklaşım, günlükleme kodunu tamamen yok etmek için ön işlemci makroları veya yapılandırmaları kullanmaktı. Bu, çalışma zamanı yükünü ortadan kaldırdı, ancak üretim acil durumlarında hata ayıklamayı önledi ve ayrı ikili yapılar gerektirdi, bu da CI/CD boru hattını karmaşıklaştırdı.
Seçilen çözüm, mesaj parametresi için @autoclosure ve @escaping kombinasyonunu uyguladı: func log(_ message: @autoclosure @escaping () -> String). Bu, doğal çağrı sözdizimini—tam olarak orijinal istekli sürümde olduğu gibi—korurken ertelemeyi garanti etti. @escaping, arka plan günlükleme kuyruğuna eşzamansız yayılımı sağladı, ancak bu, grafik güncellemeleri sırasında görünüm denetleyicilerini gerektiğinden uzun süre tutmamayı sağlamak için dikkatli bir yakalama listesi yönetimini gerektirdi.
Sonuç, üretim CPU kullanımını %28 oranında azaltarak saniyede 50,000 tıklama işlemini başarıyla gerçekleştirdi. Ancak, ekip, mesaj kapanışı self.marketData aracılığıyla kendisini örtük olarak yakaladığında, görünüm denetleyicilerini navigasyon geçişlerinde canlı tutarak bir tutma döngüsü keşfetti. Açık yakalama listeleri [weak self] bunu çözdü, ancak regresyonu önlemek için linter kuralları gerektirdi.
@autoclosure neden değişkenleri sayıya göre değil de referansla yakalar ve eğer kapanış eşzamansız çalıştırılırsa bu neden beklenmeyen değişikliklere yol açabilir?
Varsayılan olarak, Swift'te kapanışlar değişkenleri referansla yakalar, standart kapanış anlamsallığı ile tutarlılığı sağlamak için. Bir @autoclosure @escaping parametresi, dış kapsamdan bir var yakaladığında ve işlev kapanışı daha sonra çalıştırıyorsa (örneğin, bir arka plan kuyruğunda), çağrı yeri ile yürütme zamanı arasında o değişkende yapılan değişiklikler kapanış içinde görünür hale gelir. Bu, istekli değerlendirmeden farklıdır; burada değer çağrı yerinde sabitlenmiştir. Değer yakalamak için, [val = variable] gibi bir yakalama listesinde değişkeni açıkça gölgelemeniz gerekir; ancak, bu sözdizimi otomatik kapanışı kullanırken nadiren kullanılır çünkü örtük bir doğası vardır.
Derleyici, kaçış olmayan @autoclosure parametrelerini SIL düzeyinde, kaçış olan varyantlarla karşılaştırıldığında nasıl optimize eder ve bu optimizasyonlarla ilgili hangi sınırlamalar bulunmaktadır?
Swift derleyicisi, kaçış olmayan otomatik kapanışı, yığıtta tahsis edilen bir bağlamla doğrudan bir işlev işaretçisi olarak ele alır; eğer çağrılan işlev hemen onu çağırıyorsa, kapanış gövdesini tamamen işlev spesiyalizasyonu aracılığıyla içerebilir. Bu, yığın tahsisini ve referans sayma yükünü ortadan kaldırır. Ancak, bir kez @escaping olarak işaretlendikten sonra, kapanışın bağlamını işlev kapsamını aşacak şekilde heap'te tahsis etmesi gerekir ve ARC tutma/serbest bırakma trafiği doğurur. Adaylar, kaçış olmayan otomatik kapanışın başka bir kaçış olmayan işleve geçirildiğinde belirli optimizasyonların engellenebileceğini sıklıkla gözden kaçırır; bu, iç içe geçmiş thunk zincirleri oluşturarak içermeyi engeller.
@autoclosure ve kapanış gövdesinin bir atma ifadesi içerdiği durumlarda rethrows anahtar kelimesi arasında ne tür özel bir etkileşim gerçekleşir ve bu durum API tasarımı için neden önemlidir?
Bir işlev rethrows ile işaretlendiğinde ve bir atma @autoclosure kabul ettiğinde, derleyici tek atmanın yalnızca otomatik kapanış çağrısından kaynaklandığını doğrular. Bu, işlevin kendisi throws ile işaretlenmeden hataları yaymasına izin verir ve atma yapmayan çağrı yerleri için temiz bir arayüz sağlar. Bu önemlidir çünkü try lhs || expensiveFailableRhs() gibi kısa devre operatörlerinin önünü açar; burada sağ taraf yalnızca sol yanlışsa değerlendirilir ve atılır. Adaylar sık sık, rethrows'un otomatik kapanış ile, kapanışın tek atma bileşeni olması gerektiğini gözden kaçırır; eğer işlev gövdesi doğrudan başka atma işlemleri yapıyorsa, derleyici rethrowsAnnotations'ını reddeder.