3. Metamorphosis: Ars Generalis

Written by Aaqib Hussain

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]
}

This works, but you’ve already created a problem. The core logic, which involves fetching a list of items, is the same. If you later add a TransactionDataSource, you’ll end up copying and pasting the same idea again. This shows that you’re working with concrete details rather than abstract patterns.

The solution is to create a single, generic blueprint that models the data-fetching pattern. By using associatedtype, you can define a unified protocol to manage them all.

protocol DataSource {
  associatedtype Item
  func fetchItems() -> [Item]
}

Now, a UserDataSource simply implements DataSource and specifies its Item as User. This isn’t just about saving a few lines of code; it’s a conceptual leap. You’ve established a unified abstraction for a broad class of problems, enabling you to create other components that can work with any DataSource, regardless of the specific item it provides.

At this point, you might be wondering, “What is happening here? I still need to implement fetchItems() methods for both UserDataSource and ProductDataSource.” You are right to think that.

This becomes valuable when consuming these data sources. Consider if you were to pass them around. You would have no choice but to inject both like this:

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.")
}

Here, you’ve duplicated the logic in displayUserCount() and displayProductCount(). If you add a TransactionDataSource, you’ll need to write a third function, displayTransactionCount(). This code is fragile, repetitive, and doesn’t scale well.

Introducing DataSource here solves this problem. You can pass it around like this:

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).")
}

This single generic function removes duplication, allowing it to work with any DataSource while ensuring compile-time type safety.

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.

A network request typically includes several key components: a path, an HTTP method, an optional request body, and a specific response type you expect to receive. Something like:

enum HTTPMethod: String {
  case post
  case get
}

protocol APIRequest {
  associatedtype RequestBody: Encodable
  associatedtype Response: Decodable
  
  var path: String { get }
  var method: HTTPMethod { get }
}

Here, the RequestBody represents the encodable data you send with the request, and Response represents the decodable type you expect to receive.

To implement a specific request to a particular endpoint, you create a struct conforming to this protocol. For example, creating a request would look something like this:

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
}

This pattern is incredibly powerful. It creates a collection of lightweight, strongly typed request objects. A generic networking client can accept any object conforming to APIRequest with compile-time certainty about which type to encode and which to decode. This eliminates the common pitfall of accidentally decoding the wrong model from an API response.

Note: You cannot have an optional associated type. You must either provide an empty type or omit that associated type from the protocol entirely.

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.

Revisiting the DataSource protocol, imagine you need a guarantee that any item fetched from a data source can be uniquely identified and compared for equality. You can enforce this by constraining the Item associated type directly to the combination of Identifiable & Equatable.

protocol DataSource {
  associatedtype Item: Identifiable & Equatable
  func fetchItems() -> [Item]
}

With this, the DataSource protocol shifts from being a friendly host to a strict nightclub bouncer. It stands at the door and says, “Sorry, your Item isn’t Identifiable or Equatable. You’re not on the list.” The compiler becomes your enforcer, catching troublemakers long before they can cause issues at runtime.

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()]
  }
}

This approach is fundamental to designing robust, self-documenting protocols. It shifts the responsibility of meeting requirements onto the conforming type, and catches potential errors at compile time, making the abstraction safer and more explicit about its needs.

Constraining Abstractions: The where Clause

An abstraction without rules is chaotic; an abstraction with well-defined rules is powerful.

In Swift, the where clause is one of those tools that help enforce rules for generic protocols and functions. It allows adding constraints beyond basic syntax, ensuring the code is not only flexible but also fundamentally safe.

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.

Now revisit the DataSource protocol. Imagine you want to create a single generic method that checks if a data source contains a particular item. For this, the associated type must be Equatable.

You face a design choice: should you require all DataSource instances to have Equatable items by constraining the protocol, or should this requirement apply only to the specific method?

For maximum reusability, the latter is better. That’s where the where clause comes in handy to apply this local rule.

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)
}

Here’s a breakdown of the signature:

1. <S: DataSource> sets the primary constraint.
2. The where S.Item: Equatable clause adds a temporary, specific rule for this method only.

This informs the compiler: “Only allow calls to this method when the Item type of S conforms to Equatable.”

This approach combines the best of both worlds: the DataSource protocol remains simple and widely applicable, while the dataSource(contains:in:) method is assured to be type-safe without enforcing a permanent restriction on the protocol itself.

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.

Consider an API that provides a list of users and a local cache that stores them. You want to write a single generic method that identifies which API users are not yet in the cache. This comparison is only possible if both the API and the cache operate on the same item type.

The protocol definitions might look like this. Note that the items must be Hashable to perform an efficient diff using a Set.

protocol APIResponse {
  associatedtype Item: Hashable
  var items: [Item] { get }
}

protocol DataCache {
  associatedtype Item: Hashable
  func getCachedItems() -> Set<Item>
}

Now, you can write a generic function that is guaranteed to be safe.

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)
}

The key here is the where Response.Item == Cache.Item clause. It instructs the compiler to allow this method only when both associated types match.

Here’s an example of how it behaves:

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

As you can see, the compiler immediately stops the build. The where clause prevents accidental comparisons between User and Product. This is the power of compile-time safety; the bug is caught before the app can run.

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.

This isn’t just magic: it’s a complex compiler technique called generic specialization. Understanding this process is key to appreciating why generics are not only a tool for abstraction but also for writing extremely fast code. You’ll now examine how the compiler converts your abstract blueprints into highly optimized machine code.

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.

Here is an analogy to understand it better:

Imagine you’re a blacksmith in medieval times with a master blueprint for a sword. When a knight comes to you and asks for a steel longsword, you follow the blueprint to craft that specific sword out of steel. When a royal guard requests a ceremonial bronze shortsword, you use the same blueprint to create a completely different, specialized sword out of bronze. The blueprint is generic; the swords it produces are specialized.

In that way, the Swift compiler is like that blacksmith. Consider the generic function:

func printAndReturn<T>(_ value: T) -> T {
  print("Value: \(value)")
  return value
}

When you call this function with different types in your code:

let number = printAndReturn(101)       // Called with Int
let text = printAndReturn("Bears. Beets. Battlestar Galactica")   // Called with String

At compile time, Swift does not keep generic <T> versions around. Instead, it creates two specialized, non-generic versions of the function behind the scenes, almost as if you had manually written these:

func printAndReturn_Int(_ value: Int) -> Int {
  print("Value: \(value)")
  return value
}

func printAndReturn_String(_ value: String) -> String {
  print("Value: \(value)")
  return value
}

Because these versions are created at compile time, the compiler knows the exact memory layout and can perform extensive optimizations.

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.

However, generics change this situation entirely.

Check the following code:

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)

When the compiler sees these calls, it generates specialized versions of processItems for both Array<Int> and Set<String>. Inside the specialized version for the productCategories call, the compiler knows with complete certainty that items is a Set<String> and not just some abstract Collection.

To picture how the compiler separates a single generic definition into distinct, optimized implementations, consider the following illustration:

This knowledge is a compiler superpower. It bypasses the Protocol Witness Table entirely and replaces the dynamic lookup for a property, such as .count, with a direct, hardcoded call to Set.count.

This transformation from dynamic dispatch to static dispatch is known as devirtualization. It’s one of Swift’s most important optimizations and a major reason why generics almost always outperform existentials. With generics, you can write high-level, elegant abstractions without sacrificing runtime performance.

The Performance Trade-Offs of Generics

Specialization dramatically improves runtime performance, but it comes with a trade-off: increased binary size.

This happens because the compiler creates a separate, specialized copy of your generic function for each unique concrete type you use, which causes your final binary to become larger. For example, if you have a single generic function used with 50 different types throughout your app, there will be 50 different machine code copies of that function in your final executable.

For most apps, this trade-off is reasonable. The increase in binary size is usually negligible compared to the benefits of faster runtime and better type safety. It’s essential to remember that the cost of a generic is paid during compile time and affects binary size, not at runtime.

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.

You will now cover two powerful solutions: the highly performant, generic approach that leverages compiler specialization, and the type-erasure pattern for situations that demand greater flexibility. Mastering these patterns is the key to unlocking the full architectural power of protocols in Swift.

The PAT Problem Revisited: Why It Fails

The problem with PATs arises when you use them in a Collection or any variable.

Looking back at the example from Chapter 2:

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 compiler stops here with an error message.

The reason for this error is the lack of information. When the compiler sees a type like any Logger, it has no idea of the concrete type because the type has been removed. It can only guess at it. Without knowing the concrete type and its memory layout, the compiler cannot allocate the correct amount of storage for a variable like logger. Furthermore, it can’t guarantee type safety for any method calls involving the associated type.

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.

If you go back to the earlier example:

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
}

However, the generic approach works perfectly:

func runLogger<T: Logger>(_ logger: T, message: T.Message) where T.Message == String {
  logger.log(message)
}

When you use <T: Logger>, the compiler specializes your code. It generates a unique runLogger instance for each Logger type. This enables devirtualization, leading to fast static dispatch. You can keep your code abstract and high-level, and the compiler still ensures it runs efficiently.

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.

The purpose of type erasure is to hide the complex details of a protocol, such as its associated types, from the public-facing API by wrapping them in a concrete type. You’ll create your own concrete struct, AnyLogger, which manages the complexity internally while presenting a simple, uniform interface.

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.

Instead of storing the concrete logger directly in the struct AnyLogger, you’ll store a reference to it on the heap because storing it directly in a struct isn’t possible due to an unknown type and potential size differences. All class references have the same size.

The pattern works as follows:

1. Define a private, internal base class that acts as an abstract interface.
2. Define a second private, generic class that inherits from the base class. This class holds the actual concrete Logger.
3. The public-facing AnyLogger struct contains an instance of the base abstract interface.

You can think of AnyLogger as a universal remote control. AnyLogger has a consistent set of buttons, in this case, the log method. The magic happens inside, where it can be programmed to control different types, like the Logger. The user doesn’t need to understand the complex details of the remote internally.

Implementing a Type-Erased Wrapper

To build AnyLogger<Message> step-by-step, start by analyzing how each part contributes to the pattern.

Step 1: The Internal Blueprint

First, define the two private classes that will serve as the box. Classes are used because you need reference semantics to store them on the heap.

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)
  }
}

AnyLoggerBase is the base class that functions as the wrapper’s “abstract interface.” It is generic over Message to match the public struct’s generic parameter. The fatalError in the base class indicates an “abstract” class — it’s not meant to be used directly, only subclassed.

ConcreteLogger is the generic class that contains the concrete logger. It inherits from the base class and overrides its methods.

Step 2: The Public-Facing Wrapper

Now define the AnyLogger struct and expose it as an external API for consumption.

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)
  }
}

What really matters is the generic initializer. When you create an AnyLogger, you specify a concrete Logger instance, like a FileLogger or ConsoleLogger defined in Chapter 2. The initializer then creates a ConcreteLogger for that type and stores it in the base property. The where Concrete.Message == Message clause ensures that during compilation, you can’t accidentally use a Logger that expects Data as an AnyLogger<String>.

Step 3: Using the Wrapper

With the AnyLogger wrapper in place, you can store different types of loggers, like FileLogger and ConsoleLogger, in a single, homogeneous collection. Instead of working directly with any Logger existential, you now have a concrete type, AnyLogger<String>, which offers a simple interface.

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.")
}

This follows the same pattern Apple uses for APIs like AnyPublisher from Combine and AnyView from SwiftUI. While it offers maximum flexibility, it comes at the expense of performance due to heap allocation and dynamic dispatch. It should only be used when a generic approach is not feasible.

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.

The Result type solves this problem with the power and clarity of a generic type. At its core, Result is an enum with two mutually exclusive cases:

@frozen enum Result<Success, Failure: Error> {
  case success(Success)
  case failure(Failure)
}

This is a powerful concept that represents a value limited to one of several distinct options. As an enum, an instance of Result can only be in one of these states at a time, holding either a .success or a .failure, but never both. This straightforward structure eliminates the ambiguity present in the old tuple-based approach.

The Failure type in the Result generic is restricted to elements that conform to Swift’s standard Error protocol. This ensures that Result integrates smoothly with Swift’s error handling system. This standardization is extremely powerful, enabling you to write generic methods that can, for example, log the error from any Result type, confident that the failure will always be a descriptive Error.

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>

It takes a closure with a Success and transforms it into a NewSuccess, then returns a new Result containing the value, while leaving the Failure unchanged. This is especially useful for processing data. For example, if you have a Result<Data, Error>, you can map it into a Result<UIImage, Error> without needing to manually check for a successful case first.

Here is a sample usage of the map function.

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)")
}

Following is a breakdown of the whole situation:

1. Returns a Result<String, FetchError>.
2. Use map to transform the successful String into a User object.
3. Depending on what fetchUserData() returns, either .success or .failure.

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>

The main difference here is that the flatMap closure returns a Result. This allows you to chain multiple failable operations together cleanly. In summary, use map for simple transformations and use flatMap to chain another failable operation.

Consider the following example:

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)
  }
}

Now, if you attempt the following:

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>
}

This will leave you with a chain of Result<Result<User, ProfileError>, ProfileError>. To fix that, you use flatMap

let result: Result<User, ProfileError> = userResult.flatMap { id in
  return fetchUserProfile(for: id)
}

This gives you a clean Result<User, ProfileError>.

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)
  }
}

The code that invokes the method is forced by the compiler to manage both success and failure states. A switch statement is the clearest way to handle the outcome.

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
}

This pattern offers three main advantages: explicitness (you must acknowledge both outcomes), clarity (the code’s purpose is clear), and type safety (the compiler knows the specific types of user and error).

Key Points

• Writing multiple, similar concrete protocols (such as UserDataSource and ProductDataSource) 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 associatedtype creates 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 displayItemCount function) 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 generic APIRequest with both a RequestBody and a Response.
• You can enforce universal rules by constraining an associatedtype directly in its definition (e.g., associatedtype Item: Identifiable & Equatable), making the protocol itself stricter and more self-documenting.
• The where clause 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 a where clause 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 to Users, not Products.
• 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 map on a Result for simple, non-failable transformations of a success value. Use flatMap to chain an operation that can also fail, avoiding nested Result types.

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.

The goal of this chapter was not only to turn you into a pro with generics and familiarize you with its details but also to encourage you to consider all the trade-offs of writing abstract code, which will ultimately help you think like an experienced engineer.