Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt

Use this file to discover all available pages before exploring further.

The @frozen attribute is a declaration modifier applied to structures and enumerations to guarantee that their internal layout or set of cases will never change in future versions of a compiled module. By explicitly fixing the type’s Application Binary Interface (ABI), it allows the Swift compiler to perform aggressive memory and control-flow optimizations across module boundaries.

​
Syntax and Declaration Requirements

The attribute is placed directly before the struct or enum keyword. Because freezing a type exposes its internal layout to the public ABI, the compiler enforces strict access control rules:
  1. Type Visibility: The @frozen attribute can only be applied to types declared as public or marked with the @usableFromInline attribute. Applying it to standard internal, fileprivate, or private types results in a compiler error.
  2. Property Visibility: Stored properties within a @frozen structure cannot have private or fileprivate access control. Furthermore, standard internal stored properties are invalid on their own; any internal stored property must be explicitly marked with the @usableFromInline attribute so its layout is exposed to the ABI.
@frozen
public enum ConnectionState {
    case connected
    case disconnected
}

@frozen
@usableFromInline
internal struct Coordinate {
    // Internal stored properties must be exposed to the ABI
    @usableFromInline
    internal var latitude: Double
    
    @usableFromInline
    internal var longitude: Double
}

​
Compiler Mechanics and ABI Implications

When a module is compiled with library evolution enabled (-enable-library-evolution), the Swift compiler normally treats public structs and enums as resilient. Resilient types require indirect memory access and dynamic allocation because their size and layout might change in future dynamic library updates. Applying @frozen strips this resilience, enforcing the following mechanical changes: For Enumerations:
  • Strict Exhaustivity: The compiler guarantees that no new cases will ever be added. Consequently, switch statements evaluating a frozen enum from an external module are strictly exhaustive and do not require an @unknown default clause to handle future, uncompiled cases.
  • Payload Layout: The memory footprint required to store the enum’s cases and associated values is permanently locked.
For Structures:
  • Fixed Memory Layout: The compiler knows the exact size and alignment of the struct at compile time.
  • Direct Access: Clients of the module can allocate the struct directly on the stack and access its stored properties via direct memory offsets, bypassing the overhead of dynamic getter/setter indirection.
  • Property Type Restrictions: All stored properties within a frozen struct must have a fixed layout. This includes primitive types, other frozen types, and types with an inherently fixed memory footprint (represented as pointers), such as reference types (classes), existential types (protocols), and function types (closures). Adding, removing, or reordering stored properties in future versions will break ABI compatibility.

​
Compilation Context

The @frozen attribute is strictly an ABI-level contract. If a Swift target is not compiled with library evolution enabled (which is the default for standard executable applications), all structs and enums are implicitly treated as frozen by the compiler. In these non-evolution contexts, explicitly applying the @frozen attribute is permitted but has no effect. The compiler intentionally does not emit a warning for this redundancy, ensuring that source code remains compatible across different compilation environments and package configurations.
Master Swift with Deep Grasping Methodology!Learn More