Swift 5.0 ile birlikte kütüphane evrimi desteğiyle tanıtılan @frozen niteliği, API genişletilebilirliği ve ikili kararlılık arasındaki gerginliği çözmek için tasarlandı. Bu mekanizmadan önce, dayanıklı kütüphanelerdeki tüm kamu enum'ları örtük olarak donmamıştı ve bu, derleyicinin gelecekteki sürümlerin bilinmeyen durumlar ekleyebileceğini varsaymasına neden oluyordu. Bu varsayım, kompakt, sabit boyutlu düzenlerin üretilmesini engelledi ve istemci kodunda savunma programlama kalıplarını zorunlu kıldı. Bu nitelik, enum'un durum envanterinin sonsuza dek değişmeyeceğine dair resmi bir garanti sağlar ve bu da saldırgan optimizasyonlara olanak tanır.
Bir kütüphane bu niteliği olmadan bir enum yayımladığında sorun ortaya çıkar. Swift, enum'ı dayanıklı olarak değerlendirmek zorunda kalır, bu da gelecekteki durum ayrımcıları ve ilgili değer düzenleri için bellek temsilinde değişken alan ayırır. Bu, istemci switch'lerinin bir @unknown default durumu içermesini zorunlu kılarak, tüm mantıksal durumların ele alındığını derleme zamanında doğrulama yeteneğini etkili bir şekilde devre dışı bırakır. Böyle bir varsayılan olmadan, kütüphaneye bir durum eklemek, yeni ayrımcı değerini işleme koyacak kodu içermeyen önceden derlenmiş istemci ikiliklerinde tanımsız davranışa yol açar, bu da çökmesine veya bellek bozulmasına neden olabilir.
Çözüm, @frozen niteliğinin kalıcı bir sözleşme kurmasındadır. Bir enum'u donmuş olarak işaretleyerek, kütüphane yazarı durumların setinin asla değişmeyeceğini taahhüt eder, bu da derleyicinin sabit tam sayı etiketleri atamasına ve kararlı, kompakt bir bellek düzeni kullanmasına olanak tanır. Bu, derleyicinin ayrımcının tüm mümkün bit desenlerinin bilinen durumlara karşılık geldiğini kanıtlayabildiğinden, varsayılan durumlar olmadan tam switch durumlarını mümkün kılar. Ortaya çıkan ABI kararlılığı, enum'un boyutunun ve hizalamasının kütüphane sürümleri boyunca sabit kalmasını sağlar, bu arada istemci kodu sıçrama tablosu optimizasyonlarından ve her durumu zorunlu kılma faydalarından yararlanır.
// Kütüphane -enable-library-evolution ile derlendiğinde @frozen public enum LoadState { case idle case loading case loaded(Data) } // Ayrı bir modüldeki istemci kodu func updateUI(for state: LoadState) { switch state { case .idle: print("Bekleniyor") case .loading: print("Dönme") case .loaded: print("İçerik") // Derleyici tamlığı doğruluyor; varsayılan gerekli değil } }
Bir lojistik şirketinin platform ekibi, .truck, .air ve .ship durumlarına sahip bir TransportMode enum'u içeren bir Swift paketi yayımlıyordu. .drone ve .rail eklemeyi umduklarından, kütüphaneyi başlangıçta @frozen niteliği olmadan dağıttılar. İstemci ekipleri, Xcode'un @unknown default ifadeleri olmadan switch’leri derlemeyi reddettiğini rapor ettiler ve burada .ship durumunu taşıma maliyet hesaplamalarında işleme almayı unuttukları mantık hatalarını gizlediler.
Ekip, bunu çözmek için üç mimari yaklaşımı değerlendirdi.
İlk olarak, donmamış durumu koruyarak istemcilerin @unknown default işleyicilerini yazdığına dair ağır linting yatırımı yapabilirlerdi. Bu, taşımacılık modları eklemek için büyük sürüm artışları olmadan esnekliği korudu ancak bu, derleme zamanında tamlık kontrolünü kalıcı olarak devre dışı bırakıyordu. Ayrıca, her enum örneği, sürücülerin cihazlarına gönderilen seri rota paketlerini şişiren dayanıklılık meta verileri taşıdığı için ikili boyut fazlalığını çözmedi.
İkincisi, enum'u tamsayı sabitleri ile desteklenen bir RawRepresentable yapı ile değiştirebilirlerdi. Bu, sabit bir bellek düzeni sağlar ve yeni modları eklemeye olanak tanırdı, ancak Swift'in desen eşleme yeteneklerini tamamen feda ederdi. Geliştiriciler uzun if-else zincirlerine zorlanır ve derleyici, tüm olası taşımacılık durumlarının kritik yol bulma algoritmalarında ele alındığını doğrulayamazdı.
Üçüncüsü, enum'a @frozen uygulayarak mevcut üç duruma bağlı kalmayı ve gelecekteki genişlemeler için ayrı bir ExtendedTransportMode sarmalayıcı oluşturmayı tercih edebilirlerdi. Bu, dayanıklılık fazlalığını ortadan kaldırır, tam switch derlemesine olanak tanır ve her istemcinin tüm mevcut modları açıkça ele almasını garanti ederdi. Ancak, bu, orijinal enum'u değiştirme açısından kalıcı bir kısıtlama ve hiçbir temel ekleme yapmadan sürümlendirme gerekliliği ile sonuçlandırırdı.
Üçüncü çözümü seçtiler. TransportMode'u dondurduktan sonra, derleme sırasında kendi analiz panelinde iki işlenmemiş switch durumunu hemen keşfettiler. Dayanıklılık meta verilerinin kaldırılması, iletilen rota nesnelerinin boyutunu %18 oranında azaltırken, açık mimari sınır, temel taşımacılık mantığı ile deneysel modlar arasında daha temiz bir ayrım yapılmasını sağladı.
Başka bir durumu donmamış bir kamu enum'a eklemek, istemci kaynak kodu hala başarıyla derlense bile neden ikili uyumluluğu bozar?
Swift, bir dayanıklı modülü derlediğinde, donmamış enum'lar, gelecekteki durum ayrımcıları için alan ayıran değişken genişlikte bir temsil kullanır. Eğer kütüphane ardından bir durum eklerse, enum'un çalışma zamanı düzeneği değişir; örneğin, ayrımcı tamsayısı, yeni etiket için 8 bitten 16 bite genişleyebilir. Önceden derlenmiş istemci ikilikleri eski düzeni bekler ve yalnızca orijinal etiket aralığını hesaba katan sıçrama tablolarına veya koşullu dallara sahiptir. Bu ikilikler yeni ayrımcı değerini aldığında, geçersiz kod yollarını çalıştırabilir veya beklenen yük sınırının ötesinde bellek okuyabilir, bu da @unknown default ifadeleri ile kaynağın düzeyinde önlenemeyen çökmelere yol açar.
@frozen, dolaylı durumlar veya dayanıklı türlerden oluşan ilişkili değerler içeren enum'lar ile nasıl etkileşir?
@frozen, durumların kimliğinin ve sayısının sabit kalmasını garanti eder; ancak ilişkili değerlerin boyutunu dondurmaz. Eğer bir durum, donmamış bir yapı veya bir sınıf referansı taşıyan bir yük taşıyorsa, enum'un ABI kararlılığı, sabit ayrımcı etiketine atıfta bulunurken, yük depolaması hala işaretçiler veya değer tanık tabloları aracılığıyla dinamik boyutlandırma kullanabilir. Adaylar genellikle @frozen'in tüm bellek ayak izini, dahil yük boyutlarını da sabitlediğini yanlış varsayar; gerçekte, optimizasyon esas olarak etikete uygulanır ve ilişkili değerler, tipleri dayanıklı veya bilinmeyen boyutları içeriyorsa hala çalışma zamanı düzen hesaplamaları gerektirebilir.
Donmuş bir enum, dayanıklı olmayan bir modül içinde tanımlanabilir mi ve bunu yapmanın uzun vadeli etkileri nelerdir?
Evet, @frozen, kütüphane evrim sınırlarının kapalı olduğu normal uygulama hedefleri içinde enum'lara uygulanabilir. Bu bağlamda, nitelik, niyetin belgesi olarak işlev görür, çünkü modül içindeki tüm enum'lar fiilen donmuş durumdadır. Ancak, adaylar sıkça @frozen'in kalıcı bir ABI sözleşmesi oluşturduğunu gözden kaçırırlar; eğer modül daha sonra dayanıklı bir kütüphane çerçevesine çıkarılursa, enum, mevcut istemcilerle ikili uyumluluğu bozacak şekilde dondurulamaz veya genişletilemez. Enum'ların ilk geliştirme aşamasında donmuş olarak işaretlenmesi, projenin mimarisi geliştikçe kazara ABI ihlallerine karşı kod tabanını geleceğe yönelik korur.