The @inlinable attribute instructs the Swift compiler to serialize a function’s implementation into the module interface file, allowing the body to be copied directly into client modules at compile time to enable aggressive optimizations like generic specialization and constant folding. However, because inlined code must resolve all symbol references within the client’s compilation unit, any internal types, functions, or properties accessed by the @inlinable function must be marked with @usableFromInline, which exposes them to the compiler without publishing them as public API.
// Inside a resilient framework module @usableFromInline internal struct InternalBuffer { @usableFromInline var storage: [Int] } @inlinable public func fastSum(_ buffer: InternalBuffer) -> Int { // Can access internal storage due to @usableFromInline return buffer.storage.reduce(0, +) }
This combination allows library authors to offer zero-cost abstractions where generic code is monomorphized in the client binary, though it sacrifices some ABI flexibility because the function body becomes part of the stable binary interface.
A team developing a high-throughput machine learning framework needed to expose a generic matrix multiplication function matmul<T: Numeric> to client applications, but profiling revealed that cross-module function call overhead and lack of specialization reduced performance by forty percent compared to hand-written loops. The library was distributed as a binary Swift package, so source-level optimizations were not available to clients.
One approach was to make all helper types and the implementation function public, exposing every detail of the internal buffer management and stride calculations. While this would have permitted inlining, it would have locked the team into maintaining those specific internal types as stable API forever, preventing future refactoring and cluttering the public interface with implementation details that consumers should never touch directly.
Another option considered was using @inline(__always), which aggressively inlines code within the same module but does not export the function body to other modules; this would have kept the API clean but would not have allowed the client compiler to specialize the generic T for specific numeric types like Float16 or Double, leaving runtime dispatch overhead intact and failing to meet the performance targets.
The engineers ultimately marked the entry point with @inlinable and annotated the internal buffer structures and arithmetic helpers with @usableFromInline. This strategy exposed just enough implementation detail to the compiler to allow full monomorphization and inlining at client call sites while keeping the symbols out of the public documentation. The result was that client applications achieved performance identical to manually unrolled C code, though the framework’s binary size increased slightly due to code duplication across modules, and the team accepted that patching the function would require clients to recompile.
What is the fundamental distinction between @inlinable and @inline(__always) regarding cross-module boundaries?
@inlinable is a module interface contract that writes the function body into the .swiftinterface file, permitting the compiler to emit the implementation directly into dependent modules during their compilation, which is essential for cross-module generic specialization. In contrast, @inline(__always) is merely an optimization hint for the local compilation unit; it instructs the optimizer to flatten the call stack within the module but does not make the body available to external compilers, meaning client modules still invoke the function through resilient indirection and cannot eliminate generic dispatch overhead.
Why does Swift require @usableFromInline for internal symbols referenced by @inlinable functions rather than simply inferring visibility?
When a function is inlined into a client module, the compiler must generate concrete machine instructions for that code at the call site, which requires complete type metadata and symbol addresses for every referenced entity; internal symbols are intentionally excluded from the module interface to enforce encapsulation. @usableFromInline acts as a special compiler-only visibility level that exposes the symbol’s definition in the interface file without making it accessible to client source code, satisfying the code generation requirements while maintaining source-level privacy and preventing accidental API leakage.
How does adopting @inlinable affect the ABI stability and binary size characteristics of a Swift library?
Marking a function @inlinable embeds its implementation into the library’s ABI, meaning any change to the function body—such as fixing a bug or improving an algorithm—constitutes a breaking binary change that requires all client modules to be recompiled to observe the update, unlike resilient functions where the implementation can be swapped independently. Furthermore, because the compiler duplicates the function body at every call site across all client binaries rather than referencing a single shared library address, @inlinable significantly increases the total binary size of the final application, making it inappropriate for large, infrequently-called utility functions.