3.
Metamorphosis: Ars Generalis
Written by Aaqib Hussain
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.
Unlock now
The term “algorithm” is a Latinization of the name of the 9th-century Persian mathematician Muhammad ibn Musa Al-Khwarizmi, the father of algebra. His work was revolutionary because it established abstract rules for solving entire classes of problems, rather than just individual equations. He taught the world to think in patterns.
That same leap from a specific number to an abstract variable is the core idea behind modern programming. Where Al-Khwarizmi used a symbol like x (not a literal x but a variant of it from the Persian alphabet) to represent any number, Swift uses generics (like <T>) to represent any type.
In this chapter, you will adopt that same mindset. You will master Swift’s generic system to create powerful, abstract blueprints, such as reusable parsers and type-safe network requests, that solve entire classes of programming problems with elegant, reusable solutions.
Reliable software resides in scalable architecture and a well-defined codebase.
Designing with Generic Protocols
By this point, you already understand how associated types work. Now, it’s time to apply that knowledge and delve deeper into the architecture side of things. Knowing what a tool is and knowing how to use it are completely different skills. In this section, you’ll use generic protocols to create systems that are flexible, abstract, and safe.
You’ll begin by consolidating repetitive concrete protocols into a single reusable generic blueprint. Then you’ll design protocols with multiple associated types, and finally, learn how to enforce rules on the blueprints themselves.
Moving from Concrete to Abstract
Writing great architecture is all about identifying common patterns and minimizing duplication. Now imagine you’re building an app that needs to fetch different kinds of data. You might begin by defining a protocol for each kind.
protocol UserDataSource {
func fetchUsers() -> [User]
}
protocol ProductDataSource {
func fetchProducts() -> [Product]
}
protocol DataSource {
associatedtype Item
func fetchItems() -> [Item]
}
func displayUserCount(from source: UserDataSource) {
let count = source.fetchUsers().count
print("There are \(count) users.")
}
func displayProductCount(from source: ProductDataSource) {
let count = source.fetchProducts().count
print("There are \(count) products.")
}
struct User {
// ... Some properties
}
struct UserDataSourceImpl: DataSource {
typealias Item = User
func fetchItems() -> [User] {
[User()]
}
}
struct Product {
// ... Some properties
}
struct ProductDataSourceImpl: DataSource {
typealias Item = Product
func fetchItems() -> [Product] {
[Product()]
}
}
func displayItemCount<S: DataSource>(from source: S) {
let count = source.fetchItems().count
print("There are \(count) items of type \(S.Item.self).")
}
Designing with Multiple Associated Types
A generic protocol doesn’t mean it can only have one associated type. For more complex interactions, it can include multiple associated types to create a comprehensive, descriptive contract that guarantees type safety across several related types. A real-world example of this pattern is a network request layer.
enum HTTPMethod: String {
case post
case get
}
protocol APIRequest {
associatedtype RequestBody: Encodable
associatedtype Response: Decodable
var path: String { get }
var method: HTTPMethod { get }
}
struct User: Encodable {
// ... Some properties
}
struct UserConfirmation: Decodable {
// ... Some properties
}
struct CreateUserRequest: APIRequest {
typealias RequestBody = User
typealias Response = UserConfirmation
let path = "/users"
let method: HTTPMethod = .post
let newUser: User
}
Constraining Associated Types in the Protocol Definition
While the where clause is one way to constrain a protocol, you can also apply constraints directly to associated types within a protocol’s definition using protocol composition. This approach enforces a rule on the blueprint itself, requiring that any conforming type must use a type that meets specific criteria.
protocol DataSource {
associatedtype Item: Identifiable & Equatable
func fetchItems() -> [Item]
}
struct UserDataSourceImpl: DataSource { // Error: Type 'UserDataSourceImpl' does not conform to protocol 'DataSource'
typealias Item = User
func fetchItems() -> [User] {
[User()]
}
}
struct ProductDataSourceImpl: DataSource { // Error: Type 'ProductDataSourceImpl' does not conform to protocol 'DataSource'
typealias Item = Product
func fetchItems() -> [Product] {
[Product()]
}
}
Constraining Abstractions: The where Clause
An abstraction without rules is chaotic; an abstraction with well-defined rules is powerful.
Pattern 1: Constraining an Associated Type
The where clause is often used to apply constraints to an associated type in a protocol. This allows you to write generic methods that work with specific types (like DataSource), provided their nested associated type (Item) meets certain requirements.
protocol DataSource {
associatedtype Item
func fetchItems() -> [Item]
}
func dataSource<S: DataSource>(contains item: S.Item, in source: S) -> Bool where S.Item: Equatable {
return source.fetchItems().contains(item)
}
Pattern 2: Matching Two Associated Types
You can use the where clause to ensure the associated types of two different generic parameters are the same. This is useful for writing methods that manage interactions between distinct but related generic types, like a network response and a local cache.
protocol APIResponse {
associatedtype Item: Hashable
var items: [Item] { get }
}
protocol DataCache {
associatedtype Item: Hashable
func getCachedItems() -> Set<Item>
}
func findNewItems<Response: APIResponse, Cache: DataCache>(
in response: Response,
comparedTo cache: Cache
) -> Set<Response.Item> where Response.Item == Cache.Item {
let freshItems = Set(response.items)
let cachedItems = cache.getCachedItems()
return freshItems.subtracting(cachedItems)
}
struct UserResponse: APIResponse {
typealias Item = User
var items: [User] = []
}
struct UserDataCache: DataCache {
typealias Item = User
func getCachedItems() -> Set<User> {
// Some user list
return ...
}
}
struct ProductDataCache: DataCache {
typealias Item = Product
func getCachedItems() -> Set<Product> {
// Some product list
return ....
}
}
findNewItems(in: UserResponse(), comparedTo: ProductDataCache()) // Global function 'findNewItems(in:comparedTo:)' requires the types 'UserResponse.Item' (aka 'User') and 'ProductDataCache.Item' (aka 'Product') be equivalent
The Compiler’s Secret: Generic Specialization
The question now is how Swift manages complexity without compromising performance. You might think that such high-level abstractions could lead to increased runtime costs, but in Swift, that’s rarely the case.
How the Compiler Creates Specialized Code
At its core, specialization is the process by which the compiler takes a generic method and generates distinct, concrete versions of it for each type for which it’s used.
func printAndReturn<T>(_ value: T) -> T {
print("Value: \(value)")
return value
}
let number = printAndReturn(101) // Called with Int
let text = printAndReturn("Bears. Beets. Battlestar Galactica") // Called with String
func printAndReturn_Int(_ value: Int) -> Int {
print("Value: \(value)")
return value
}
func printAndReturn_String(_ value: String) -> String {
print("Value: \(value)")
return value
}
Devirtualization: From Dynamic to Static Dispatch
Devirtualization is a powerful result of specialization that directly relates to the method dispatch concepts introduced in Chapter 2. When you use a protocol as an existential type like any SomeProtocol, the compiler doesn’t know the concrete type at runtime. To call a method, it must perform a dynamic dispatch, which adds a small but real layer of overhead.
func processItems<C: Collection>(_ items: C) {
print("Processing \(items.count) items.")
}
let userIDs: [Int] = [101, 102, 103]
let productCategories: Set<String> = ["Bears", "Beets", "Battlestar Galactica"]
processItems(userIDs)
processItems(productCategories)
The Performance Trade-Offs of Generics
Specialization dramatically improves runtime performance, but it comes with a trade-off: increased binary size.
Escaping the Existential Box: Working with PATs
Now that you understand how generics work and why they are fast, you can reason about the “existential crisis” caused by protocols with associated types (PATs). In Chapter 2, you saw that using a PAT as an existential type threw a compile error. In this section, you’ll learn exactly why that happened and how to resolve it.
The PAT Problem Revisited: Why It Fails
The problem with PATs arises when you use them in a Collection or any variable.
func runLogger(_ logger: any Logger) {
logger.log("Hello from an existential Logger!") // Member 'log' cannot be used on value of type 'any Logger'; consider using a generic constraint instead
}
The High-Performance Generic Approach
The compiler’s error message itself provides the best solution: “consider using a generic constraint instead”. This should be the default whenever possible, as it is both the simplest and most efficient way to address the problem. Instead of trying to force a PAT into an existential box, you retain the type information by making the code that uses it generic.
func runLogger(_ logger: any Logger) {
logger.log("Hello from an existential Logger!") // Member 'log' cannot be used on value of type 'any Logger'; consider using a generic constraint instead
}
func runLogger<T: Logger>(_ logger: T, message: T.Message) where T.Message == String {
logger.log(message)
}
The Architecture of Type Erasure: Deconstructing the Pattern
The generic approach is the ideal solution and works in most cases, but what if you need to pass around “any logger” as a parameter or store different kinds of loggers in a single collection? For these situations, you must turn to type erasure.
Type Erasure Explained
To be able to call the log(_ message: Message) on any Logger, you would need to hide the associatedtype from the compiler. This can be done by creating a wrapper AnyLogger. The next challenge is how a single AnyLogger wrapper can hold onto any possible Logger.
Implementing a Type-Erased Wrapper
To build AnyLogger<Message> step-by-step, start by analyzing how each part contributes to the pattern.
private class AnyLoggerBase<Message> {
func log(_ message: Message) {
fatalError("This method must be overridden")
}
}
private class ConcreteLogger<Concrete: Logger>: AnyLoggerBase<Concrete.Message> {
private let implementation: Concrete
init(_ implementation: Concrete) {
self.implementation = implementation
}
override func log(_ message: Concrete.Message) {
implementation.log(message)
}
}
struct AnyLogger<Message>: Logger {
private let base: AnyLoggerBase<Message>
init<Concrete: Logger>(_ logger: Concrete) where Concrete.Message == Message {
self.base = ConcreteLogger(logger)
}
func log(_ message: Message) {
base.log(message)
}
}
let fileLogger = FileLogger()
let consoleLogger = ConsoleLogger()
let stringLoggers: [AnyLogger] = [
AnyLogger(fileLogger),
AnyLogger(consoleLogger)
]
for logger in stringLoggers {
logger.log("This message is sent to all loggers.")
}
Anatomy of a Generic: Deconstructing Result
Result is one of the most commonly used generics in Swift. You often use it when writing networking services and processing responses. It’s a perfect example of how generics can create elegant, expressive, and incredibly safe APIs. It’s an amalgamation of the concepts you’ve learned so far, and by analyzing its design, you can see how well they work together to solve common programming problems, for example, handling the result of an operation that can either succeed or fail.
The Result Enum and Its Error Constraint
Before the introduction of Result, Swift developers usually relied on tuples for writing those methods. For example, while writing a networking service, tuples like (Data?, Error?) were often used. This approach was a major source of ambiguity, forcing developers to check all possible states. This led to a pyramid of doom with if-let chaining or deep nesting of guard let, resulting in code that was both frail and difficult to read.
@frozen enum Result<Success, Failure: Error> {
case success(Success)
case failure(Failure)
}
Analyzing Generic Methods: map and flatMap
The true elegance of Result lies in its generic methods, which let you chain operations together in a clean, functional style. These important methods are map and flatMap.
map: Transforming a Successful Value
The map<NewSuccess> only transforms the Result when the result is a success. If the result is a failure, the map does nothing and simply passes the error along. Its simplified signature looks like this:
func map<NewSuccess>(_ transform: (Success) -> NewSuccess) -> Result<NewSuccess, Failure>
struct User: Decodable {
let id: Int
let name: String
let username: String
}
enum FetchError: Error {
case networkUnavailable
case invalidData
}
func fetchUserData() -> Result<String, FetchError> {
let jsonString = """
{
"id": 1,
"name": "Michael Scott",
"username": "michaelscott"
}
"""
return .success(jsonString)
}
let fetchResult = fetchUserData() // 1
let userResult: Result<User, FetchError> = fetchResult.map { jsonString in // 2
let data = Data(jsonString.utf8)
let decoder = JSONDecoder()
let user = try! decoder.decode(User.self, from: data)
return user
}
switch userResult { // 3
case let .success(user):
print("Success! Created user: \(user.id)")
case let .failure(error):
print("Failure. Reason: \(error)")
}
flatMap: Chaining Operations That Can Also Fail
It is slightly more complex than the map function. You can use it when your transformation logic involves another operation that might fail as well. That’s when your closure also returns a Result. flatMap helps avoid nested results, such as Result<Result<User, Error>, Error>. Its simplified signature is:
func flatMap<NewSuccess>(_ transform: (Success) -> Result<NewSuccess, Failure>) -> Result<NewSuccess, Failure>
enum ProfileError: Error {
case userNotFound
case networkFailed
}
func fetchUserID(from username: String) -> Result<Int, ProfileError> {
if username == "jimhalpert" {
return .success(3)
} else {
return .failure(.userNotFound)
}
}
func fetchUserProfile(for userID: Int) -> Result<User, ProfileError> {
if userID == 3 {
return .success(User(id: 3, name: "Jim Halpert", username: "jimhalpert"))
} else {
return .failure(.networkFailed)
}
}
let userResult = fetchUserID(from: "alex")
let result: Result<Result<User, ProfileError>, ProfileError> = userResult.map { id in
return fetchUserProfile(for: id) // This returns a Result<User, ProfileError>
}
let result: Result<User, ProfileError> = userResult.flatMap { id in
return fetchUserProfile(for: id)
}
Result in Practice: Type-Safe Error Handling
Result provides a clear, safe API for common, practical scenarios, such as asynchronous network requests. Using Result for the method makes the definition straightforward. Check the snippet below:
enum NetworkError: Error {
case invalidURL
case networkRequestFailed
case decodingFailed
}
func fetchUser(id: Int) async -> Result<User, NetworkError> {
guard let url = URL(string: "https://api.example.com/users/\(id)") else {
return .failure(.invalidURL)
}
do {
let (data, _) = try await URLSession.shared.data(from: url)
let user = try JSONDecoder().decode(User.self, from: data)
return .success(user)
} catch is DecodingError {
return .failure(.decodingFailed)
} catch {
return .failure(.networkRequestFailed)
}
}
let result = await fetchUser(id: 2)
switch result {
case let .success(user):
// Update the UI with the user object
case let .failure(error):
// Show an error message to the user
}
Key Points
- Writing multiple, similar concrete protocols (such as
UserDataSourceandProductDataSource) is a sign of code duplication. The first step to writing generic code is to recognize these repeating patterns. - A single generic protocol with an
associatedtypecreates a unified, abstract blueprint that can solve an entire class of problems, making your architecture more scalable and maintainable. - The primary benefit of generic protocols isn’t just consolidating definitions; it’s enabling the creation of reusable consumer functions (such as a single
displayItemCountfunction) that can operate on any conforming type. - Protocols are not limited to one
associatedtype. You can define multiple associated types to model complex contracts, such as a genericAPIRequestwith both aRequestBodyand aResponse. - You can enforce universal rules by constraining an
associatedtypedirectly in its definition (e.g.,associatedtype Item: Identifiable & Equatable), making the protocol itself stricter and more self-documenting. - The
whereclause is a more flexible tool for applying local constraints to a single function or extension, keeping the base protocol simple and more widely applicable. A common use of awhereclause is to ensure that the associated types of two different generic types are the same (e.g.,where Response.Item == Cache.Item). - This compile-time check prevents a whole class of logical errors by ensuring you only operate on matching types, such as comparing
Users toUsers, notProducts. - Specialization is the compile-time process where Swift creates separate, concrete, and highly optimized copies of a generic function for each specific type it is used with.
- Specialization enables devirtualization, a critical optimization that replaces slower dynamic dispatch (e.g., a Protocol Witness Table lookup) with direct, high-performance static dispatch.
- The main trade-off for the incredible runtime performance of generics is a potential increase in the final app’s binary size.
- The best and most performant solution to the PAT problem is to use a generic constraint (e.g.,
<T: Logger>) instead of an existential, as this leverages specialization. - Swift’s
Result<Success, Failure: Error>is a prime example of a generic enum that provides type-safe error handling by representing one of two mutually exclusive states. - Use a
mapon aResultfor simple, non-failable transformations of a success value. UseflatMapto chain an operation that can also fail, avoiding nestedResulttypes.
Where to Go From Here?
Congratulations, you’ve reached the end of the chapter. In this chapter, you learned about the benefits and trade-offs of generics. You also found some answers to the questions you might have had from Chapter 2. Give yourself a pat on the back because you also wrote your own type erasure.