Ingevoerd met Swift 5.0, samen met ondersteuning voor bibliotheek-evolutie, was het @frozen attribuut ontworpen om de spanning tussen API-uitbreidbaarheid en binaire stabiliteit op te lossen. Voor deze mechanismen waren alle openbare enums in veerkrachtige bibliotheken impliciet niet-bevroren, waardoor de compiler moest aannemen dat toekomstige versies onbekende gevallen konden toevoegen. Deze aanname voorkwam de generatie van compacte, vaste formaten en vereiste defensieve programmeerpatronen in clientcode. Het attribuut biedt een formele garantie dat de set van enum-gevallen voor altijd onveranderlijk is, wat agressieve optimalisaties mogelijk maakt.
Het probleem ontstaat wanneer een bibliotheek een enum publiceert zonder dit attribuut. Swift moet de enum dan als veerkrachtig beschouwen en variabele ruimte in zijn geheugenrepresentatie reserveren om toekomstige gevalontwikkelaars en bijbehorende waardeopslagen te accommoderen. Dit dwingt client-switches om een @unknown default geval te bevatten, wat de compile-tijd verificatie dat alle logische toestanden worden behandeld, effectief uitschakelt. Zonder zo'n standaard zou het toevoegen van een geval aan de bibliotheek ongedefinieerd gedrag veroorzaken in vooraf gecompileerde client-binaries die niet over de code beschikken om de nieuwe discriminatiewaarde te verwerken, wat zou leiden tot crashes of geheugenbeschadiging.
De oplossing ligt in de @frozen annotatie die een permanent contract vastlegt. Door een enum als bevroren te markeren, belooft de bibliotheek auteur dat de set van gevallen nooit zal veranderen, waardoor de compiler vaste gehele tags kan toewijzen en een stabiele, compacte geheugenlay-out kan gebruiken. Dit maakt uitputtende switch-instructies zonder standaardgevallen mogelijk, aangezien de compiler kan bewijzen dat alle mogelijke bitpatronen van de discriminator overeenkomstig bekende gevallen zijn. De resulterende ABI stabiliteit zorgt ervoor dat de grootte en uitlijning van de enum constant blijven over versies van de bibliotheek, terwijl clientcode profiteert van jump-table optimalisaties en verplichte verwerking van elke staat.
// Binnen een bibliotheek gecompileerd met -enable-library-evolution @frozen public enum LoadState { case idle case loading case loaded(Data) } // Clientcode in een aparte module func updateUI(for state: LoadState) { switch state { case .idle: print("Wachten") case .loading: print("Draaischijf") case .loaded: print("Inhoud") // Compiler bevestigt exhaustiviteit; geen standaard vereist } }
Het platformteam bij een logistiek bedrijf verzond een Swift-pakket voor route-optimalisatie dat een TransportMode enum met gevallen voor .truck, .air en .ship naar buiten bracht. Omdat ze verwachtte dat ze .drone en .rail in de volgende versies zouden toevoegen, distribueerden ze de bibliotheek aanvankelijk zonder het @frozen attribuut. Klantteams rapporteerden al snel dat Xcode weigerde switches te compileren zonder @unknown default clausules, waardoor logische fouten verborgen bleven waar ze vergeten waren .ship in vrachtkostenberekeningen te behandelen.
Het team overwoog drie architecturale benaderingen om dit op te lossen.
Ten eerste, ze konden de niet-bevroren status behouden en investeren in zware linting om ervoor te zorgen dat klanten @unknown default handlers schreven die waarschuwingen logden. Dit behoudt de flexibiliteit om transportmodi toe te voegen zonder grote versieveranderingen, maar het schakelt permanent de compile-tijd exhaustiviteitcontrole uit. Het loste ook niet het binaire grootteprobleem op, aangezien elke enum-instantie veerkracht metadata droeg die de geserialiseerde routepakketten naar de apparaten van de chauffeurs opbliezen.
Ten tweede, ze konden de enum vervangen door een RawRepresentable struct die wordt ondersteund door gehele constanten. Dit zou een vaste geheugenlay-out bieden en het toevoegen van nieuwe modi mogelijk maken zonder de binaire compatibiliteit te breken, maar het zou de patroonmatchingscapabilities van Swift volledig opofferen. Ontwikkelaars zouden gedwongen worden tot verbosere if-else-ketens, en de compiler kon niet langer verifiëren dat alle mogelijke transporttoestanden werden behandeld in kritieke padalgoritmen.
Ten derde, ze konden @frozen toepassen op de enum en zich verbinden aan de bestaande drie gevallen, terwijl ze een aparte ExtendedTransportMode wrapper creëerden voor toekomstige uitbreidingen. Dit zou de veerkrachtige overhead elimineren, uitputtende switch-compilatie mogelijk maken en garanderen dat elke client expliciet alle huidige modi behandelde. De trade-off was een permanente beperking op het wijzigen van de oorspronkelijke enum en de noodzaak van versiebeheer voor fundamentele toevoegingen.
Ze kozen voor de derde oplossing. Na het bevriezen van TransportMode ontdekten ze onmiddellijk twee onbehandelde switch-gevallen in hun eigen analyse-dashboard tijdens de compilatie. Het verwijderen van veerkracht metadata verminderde de grootte van verzonden routeobjecten met 18%, en de expliciete architecturale grens dwong een schonere scheiding tussen de kerntransportlogica en experimentele modi.
Waarom breekt het toevoegen van een geval aan een niet-bevroren openbare enum de binaire compatibiliteit, zelfs wanneer de clientbronnen nog steeds succesvol compileren?
Wanneer Swift een veerkrachtige module compileert, gebruiken niet-bevroren enums een variabele breedte representatie die ruimte reserveert voor toekomstige geval discriminators. Als de bibliotheek vervolgens een geval toevoegt, verandert de runtime lay-out van de enum - bijvoorbeeld, de discriminator hele kan uitbreiden van 8 bits naar 16 bits om de nieuwe tag te accommoderen. Vooraf gecompileerde client binaries verwachten de oude lay-out en bevatten jump tables of voorwaardelijke takken die alleen rekening houden met het oorspronkelijke tagbereik. Wanneer deze binaries de nieuwe discriminatiewaarde tegenkomen, kunnen ze ongeldige codepaden uitvoeren of geheugen buiten de verwachte payload-grens lezen, wat crashes veroorzaakt die niet voorkomen kunnen worden door bron-niveau @unknown default clausules.
Hoe interageert @frozen met enums die indirecte gevallen of bijbehorende waarden van veerkrachtige types bevatten?
@frozen garandeert dat de identiteit en het aantal gevallen constant blijven, maar het bevriest de grootte van bijbehorende waarden niet. Als een geval een payload bevat van een niet-bevroren struct of een class-referentie, verwijst de ABI stabiliteit van de enum naar de vaste discriminator tag, terwijl de payload opslag mogelijk nog steeds dynamische schaalvergroting door pointers of waardegetuigen tabellen gebruikt. Kandidaten gaan vaak ten onrechte ervan uit dat @frozen de gehele geheugengrootte, inclusief payloadgroottes, vergrendelt; in werkelijkheid past de optimalisatie voornamelijk toe op de tag, en bijbehorende waarden hebben mogelijk nog steeds runtime lay-outcalculaties nodig als hun types zelf veerkrachtig zijn of onbekende groottes bevatten.
Kan een bevroren enum worden gedeclareerd binnen een niet-veerkrachtige module, en wat zijn de langetermijngevolgen van het doen daarvan?
Ja, @frozen kan worden toegepast op enums binnen reguliere applicatiedoelen waar bibliotheek evolutie is uitgeschakeld. In deze context fungeert het attribuut als documentatie van intentie, omdat alle enums binnen de module effectief zijn bevroren door het gebrek aan veerkrachtige grenzen. Kandidaten vergeten vaak dat @frozen een permanent ABI contract vormt; als de module later wordt geëxtraheerd in een veerkrachtig bibliotheekframework, kan de enum niet worden ontdooid of uitgebreid zonder de binaire compatibiliteit met bestaande klanten te verbreken. Het expliciet markeren van enums als bevroren tijdens de initiële ontwikkeling beschermt de codebasis tegen ongepaste ABI schendingen wanneer de architectuur van het project evolueert.