Khawer Khaliq

Articles

When and How to Use Value and Reference Types in Swift

This article explores the semantic differences between value and reference types, some of the defining characteristics of values and key benefits of using value types in Swift. We will also look at when to use value and reference types when designing applications.

Related articles:

Contents

Value and reference types in Swift
Value vs. reference semantics
Different notions of mutability
Defining characteristics of values
Advantages of using value types
1. Efficiency
2. Predictable code
3. Thread safety
4. No memory leaks
5. Easier testability
Designing applications with value and reference types
1. Reference types to model entities with identity
2. Value types to encapsulate domain logic and business rules
3. The importance of context
4. The “attribute-based equality” test
5. Combining value and reference types
The Swift Standard Library and the Cocoa frameworks
Conclusion

Value and reference types in Swift

Swift is a multi-paradigm programming language. It has classes, which are the building blocks of object-oriented programming. Classes in Swift can define properties and methods, specify initializers, conform to protocols, support inheritance and enable polymorphism. Swift is also a protocol-oriented programming language, with feature-rich protocols and structs, enabling abstraction and polymorphism without using inheritance. In Swift, functions are first-class types which can be assigned to variables, passed into other functions as arguments and returned from other functions. Swift thus also lends itself to functional programming.

The biggest difference that programmers coming from many object-oriented languages to Swift notice is the rich functionality offered by structs. Swift structs can define properties and methods, specify initializers and conform to protocols. With the exception of inheritance, whatever you can do with a class, you can also do with a struct. This triggers the question of when and how to use structs and classes. In a more general sense, it is a question of when and how to use value types and reference types in Swift.

Just for the sake of completeness, structs are not the only value types in Swift. Enums and tuples are also value types. Similarly, classes are not the only reference types. Functions are also reference types. Functions, enums and tuples, however, are more specialized in how and when they are used. The debate about value and reference types in Swift centres mostly around structs and classes. This is the primary focus of this post and the terms value type and reference type will be used interchangeably with the terms struct and class respectively.

Let’s start with some first principles, the difference between value and reference semantics.

Value vs. reference semantics

With value semantics, a variable and the data assigned to the variable are logically unified. Since variables exist on the stack, value types in Swift are said to be stack-allocated. To be precise, all value type instances will not always be on the stack. Some may exist only in CPU registers while others may actually be allocated on the heap. In a logical sense though, value type instances can be thought of as being contained in the variables to which they are assigned. There is a one-to-one relationship between the variable and the data. The value held by a variable cannot be manipulated independently of the variable.

With reference semantics, on the other hand, the variable and the data are distinct. Reference type instances are allocated on the heap and the variable contains only a reference to the location in memory where the data is stored. It is possible and quite common for there to be multiple variables with references to the same instance. Any of these references can be used to manipulate the instance.

This has implications for what happens when a value or reference type instance is assigned to a new variable or passed into a function. Since a value type instance can have only one owner, the instance is copied and the copy is assigned to the new variable or passed into the function. Each copy can be amended without affecting the others. With reference types, only the reference gets copied and the new variable or the function gets the new reference to the same instance. If a reference type instance is amended using any of the references, it will affect all other owners as they hold references to the same instance.

Let’s look at some code to see this in action. 

struct CatStruct {
    var name: String
}

let a = CatStruct(name: "Whiskers")
var b = a
b.name = "Fluffy"

print(a.name)   // Whiskers
print(b.name)   // Fluffy

We define a struct to represent a cat, with a name property. We create a CatStruct instance, assign it to a variable, then assign this variable to a new variable and modify the name property using this new variable. Since structs have value semantics, the act of assignment to the new variable results in the instance being copied and we get two separate CatStruct instances with different names.

Now, let’s do the same using a class:

class CatClass {
    init(name: String) {
        self.name = name
    }
    
    var name: String
}

let x = CatClass(name: "Whiskers")
let y = x
y.name = "Fluffy"

print(x.name)   // Fluffy
print(y.name)   // Fluffy

In this case, modifying the name property using the new variable modifies the name property for the first variable as well. This is because classes have reference semantics and the act of assignment to the new variable does not create a new instance. Both variables hold references to the same instance. This leads to implicit data sharing, which can have implications for how and when reference types should be used.

Different notions of mutability

To understand the difference between mutability in value and reference types, we have to distinguish between variable mutability and instance mutability.

As already noted, value type instances and the variables they are assigned to are logically unified. Therefore, if a variable is immutable, it makes the instance it holds immutable regardless of whether the instance has mutable properties or mutating methods. Only when a value type instance is assigned to a mutable variable does instance mutability come into play.

With reference types, the instance and the variable it is assigned to are distinct and so is their mutability. When we declare a variable holding a reference to a class instance as immutable, what we are ensuring is that the reference this variable holds will never change, i.e., it will always point to the same instance. Mutable properties of the instance can still by modified using this or any other reference to the instance. To make a class instance immutable, all its stored properties must be immutable.

In the code we just saw, it is okay to declare a which holds the first CatStruct instance as a let constant since its value is never modified. b must be declared as a var since we have modified its name property and thus its value. For CatClass, both x and y are declared as let constants, yet we were able to modify the value of the name property.

Defining characteristics of values

To gain a better understanding of when and how to use value types, we need to look at some of the defining characteristics of values:

  1. Attribute-based equality: Any two values of the same type whose corresponding attributes are equal can always be considered equal. Consider a Money type that represents monetary amounts with attributes for the currency and the amount. If we create an instance representing 5 US dollars, it will be equal to any other instance representing 5 US Dollars.
  2. Lack of Identity or life cycle: A value does not have inherent identity. It is defined only by the values of its attributes. This is true for simple values like the number 2 or the string “Swift”. It is equally true for more complex values. A value also does not have a life cycle through which state changes need to be preserved. It can be created, destroyed or recreated at any time. An instance of Money representing 5 US dollars is equal to any other instance representing 5 US dollars regardless of when or how the two instances were created.
  3. Substitutability: Not having a distinct identity or life cycle gives value types substitutability, which means that any instance can be freely substituted for another provided the two instances are equal, i.e., they pass the test of attribute-based equality. Going back to our Money type example, once we create an instance representing 5 US dollars, the application is free to create or discard copies of this instance as it sees fit. Any time we are handed an instance representing 5 US dollars, it is immaterial whether it is the same instance that we had created earlier. All we care about are the values of the attributes.

Advantages of using value types

1. Efficiency

Reference type instances are allocated on the heap, which is more expensive than stack allocation. In order to ensure that the allocated memory is freed up when a reference type instance is no longer required, there is a need to keep a count of all active references to every reference type instance and deallocate instances when there are no more references to them. Value types do not suffer from this overhead, leading to efficient instance creation and copying. Copies of value types are said to be cheap because value type instances can be copied in constant time.

Swift implements built-in extensible data structures such as String, Array, Dictionary, etc., as value types. However, these cannot be allocated on the stack because their size is not known at compile time. To be able to use heap allocation efficiently and maintain value semantics, Swift uses an optimization technique called copy-on-write. What this means is that while each copied instance is a copy in the logical sense, an actual copy on the heap is made only when a copied instance is mutated. Until then, all logical copies continue to point to the same underlying instance. This provides better performance characteristics because fewer copies are made and, when copying does take place, it involves a fixed number of reference counting operations. This performance optimization can be also be used, where required, for custom value types.

2. Predictable code

With a reference type, any part of the code that holds a reference to an instance cannot be certain about what that instance contains since it can be modified using any other reference. Since value type instances are copied on assignment with no implicit data sharing, we don’t need to think about unintended consequences of an action taken in one part of the code affecting the behavior of others. Moreover, when we see a variable declared as a let constant holding a value type instance, we can be sure that the value can never be modified regardless of how the value type is defined. This provides strong guarantees and fine-grained control over how certain parts of the code will behave, making code easier to reason about and more predictable.

One could argue that code could be written such that each time a reference type instance is handed to a new owner, a copy is created. But that would lead to a lot of defensive copying, which would be quite inefficient since copying a reference type involves significant overhead. If the reference type instance being copied has properties which are also reference type instances and we want to avoid any implicit data sharing, a deep copy would have to be created every time, which would make the performance characteristics even worse. We could also try to address the issue of shared state and mutability by making all reference types immutable. But this would still involve a lot of inefficient copying and not being able to mutate the state of a reference type would pretty much defeat the purpose of using reference types.

3. Thread safety

Value type instances can be used in a multi-threaded environment without having to worry about one thread mutating the state of an instance being used by another. Since there are no race conditions or deadlocks, there is no need to implement synchronization mechanisms. Writing multi-threaded code with value types thus becomes simpler, safer and more efficient.

4. No memory leaks

Swift uses automatic reference counting and deallocates a reference type instance when there are no references to it. This addresses the issue of memory leaks during the normal course of events. However, there can still be memory leaks through strong reference cycles, where two class instances hold strong references to each other and prevent each other from being deallocated. The same thing can happen when there is a strong reference cycle between a class instance and a closure, which are also reference types in Swift. Since value types have no references, the question of memory leaks does not arise.

5. Easier testability

Because a reference type maintains state over its life cycle, unit testing reference types often involves using mocking frameworks to observe the effects of various method calls on the state and behavior of the object under test. Moreover, since behaviour of reference type instances can change with changes in state, setup code is usually required to get the object under test in the correct state. With value types, all that matters is the value of the attributes. All we need to do, therefore, is to create a new value with the same attributes as the expected value and compare them for equality.

Designing applications with value and reference types

Value and reference types should not be seen as somehow competing with each other. They have different semantics and behaviour, which make them suitable for different purposes. The goal should be to understand and leverage the interplay of value and reference semantics to combine value and reference types in a way that best satisfies the goals of the application.

1. Reference types to model entities with identity

Most real-world domains have entities that must maintain identity and preserve state over their life cycles. Such entities should be modeled using classes.

Consider a payroll application that uses an Employee type to represent members of staff. For simplicity, let’s assume we store the first and last name of each employee. There could be two or more Employee instances with the same first and last names, but this does not make them equal, as these instances represent distinct employees in the real world.

If we assign an Employee class instance to a new variable or pass it into a function, the new reference will point to the same instance. This will ensure, for instance, that if we use one reference to record the number of hours worked by the employee in one module of the application, when another module of the application computes the monthly pay, it will use the same instance that has the correct number of hours worked. Similarly, if we update the residential address of an employee in one place, all references we have to that employee will reflect the correct address because they are references to the same instance.

Trying to use a struct to model an employee will lead to errors and inconsistencies in the application since each time an Employee instance is assigned to a new variable or passed into a function, it will be copied. Different parts of the program will end up with their own separate instances and state changes made in one part will not reflect in others.

2. Value types to encapsulate domain logic and business rules

While entities that have identity and a life cycle should be modeled using classes, we should use value types to encapsulate domain logic and business rules.

Let us consider our Employee type. Let’s assume we need to maintain information about each employee’s personal data, compensation and performance. We can create value types PersonalData, Compensation and Performance to bring together related elements of data, domain logic and business rules. This fits nicely with the Single Responsibility Principle, keeping classes from getting bloated as they are directly responsible only for maintaining identity, letting value types encapsulate the logic related to the various responsibilities of entities in the domain.

Pushing more responsibilities into value types also alleviates concerns about implicit data sharing, allowing more code to be written in a multi-threaded fashion. Copies of value type instances can freely be handed over to processes running on different threads without the need for synchronization. This can lead to performance gains and increasing responsiveness of interactive applications.

3. The importance of context

It is important to bear in mind that sometimes the choice between a value and reference type is driven by the context. Application development is not an exercise in modeling the real world in an absolute sense but rather about modeling specific aspects of the problem domain to satisfy the given use cases. The same real-world entity could, therefore, require value or reference semantics in the context of the application depending on what role the entity plays in the relevant problem domain.

Consider the CatStruct and CatClass types introduced earlier. Which one would we rather use to model our pet cat? Since the instance we create would represent an actual cat, we should use a class. When we hand over our cat to the vet to get vaccinated, for instance, we would not want the vet to vaccinate a copy of the cat, which is what would happen if we used a struct. If, however, we are designing an application dealing with dietary habits of pet cats, we should use a struct as we would be dealing with cats in a general sense and not looking to identify a specific cat. For such an application, our CatStruct will not have a name property but will likely have properties for the types of food consumed, number of servings per day, etc.

Earlier, we used the Money type as an example of a concept best modeled as a value. This is true in the context of a banking, financial or other application where we are concerned with just the attributes of money, i.e., how much and in what currency. If, however, we are building an application to control the printing, distribution and eventual disposal of physical currency, we need to think about each currency note as an entity with a unique identity and life cycle.

Similarly, for an application developed for a tire manufacturer, each tire would likely be an entity with a unique identity and life cycle, which would extend beyond the point of sale to track returns, warranty claims, etc. However, a company manufacturing cars would probably see tires for their attributes and may not want to keep track of which individual tire is used in which car, although they would see the cars they manufacture as having unique identities and life cycles.

4. The “attribute-based equality” test

Value types have no inherent identity to distinguish one instance of a type from another instance of the same type. The only way to compare them is to compare their attributes. In fact, the concept of attribute-based equality is so fundamental to value types that it can be used a guide when deciding whether a particular type should be a value type or a reference type. If two instances of a type cannot be compared for equality based solely on their attributes, then we are likely dealing with some element of identity. This usually means that either the type should be a reference type or it should be split to separate the value and reference semantics.

In practice, this means that we should be able to compare any two instances of a given value type using the Swift == operator. It follows that all value types must conform to the Equatable protocol.

5. Combining value and reference types

As already noted, it is quite normal and in fact desirable for reference types to have properties that are instances of value types to encapsulate state, express business rules and expose behaviour. These value types can be passed around in an efficient manner without having to worry about unintended consequences, thread safety, etc. But should a value type hold instances of reference types? This should generally be avoided because use of reference type properties on value types can negate the performance and other advantages of value types by introducing heap allocation, reference counting and implicit data sharing. In fact, it may cause the value type to lose its attribute-based equality, lack of identity and substitutability. It is important, therefore, to respect these boundaries and not to combine value and reference semantics in a way that will compromise the integrity of either.

There are various ways to describe how value and reference types can work together in real-world applications. As Andy Matuschak put it in this blog post: Think of objects as a thin, imperative layer above the predictable, pure value layer. In the References section of Andy’s post is a link to this talk by Gary Bernhardt, where he proposes a way of building systems using what he calls a functional core and an imperative shell. The functional core is composed of pure values, domain logic and business rules. It is easy to reason about, facilitates concurrency and simplifies testing because it is isolated from external dependencies by the imperative shell, which preserves state and connects to the world of user interfaces, persistence mechanisms, networks, etc.

The Swift Standard Library and the Cocoa frameworks

The Swift Standard Library is composed predominantly of value types. All basic built-in types and collections have been implemented as structs. The frameworks that form part of Cocoa, however, are composed mostly of classes. Some of this is required because classes are the appropriate way to model view controllers, user interface elements, network connections, file handlers, etc.

But Cocoa also has a number of classes in the Foundation framework that would rather be value types but exist as reference types because they are written in Objective-C. This is where the Swift Foundation overlay comes in, providing bridged value types for a growing number of Objective-C reference types. For more details on bridged types and how Swift interoperates with Cocoa frameworks, see this page in the Apple developer library.

Conclusion

Swift provides powerful and efficient value types that can be used to make parts of our code more efficient, predictable and thread-safe. This requires understanding the differences between value and reference semantics to be able to combine value and reference types in a way that best satisfies the goals of the application.

Thank you for reading! I always appreciate constructive comments and feedback. Please feel free to leave a comment in the comments section of this post or start a discussion on Twitter.

Swift Protocols Don’t Play Nice With Equatable. Or Can They? (Part Two)

*** Updated for Swift 4.1 ***

This is Part Two of a two-part article. Part One demonstrates how making protocols conform to Equatable renders us unable to use the protocols as types and why trying to implement equality functions on protocols, even without Equatable conformance, can lead to erroneous results in some cases and is impossible in others.

This part uses type erasure to implement equality comparisons and Equatable conformance at the protocol level. This allows us to program to abstractions using protocol types while being able to safely make equality comparisons and also use functionality provided by the Swift Standard Library which is available only to types that conform to Equatable.

It would be useful to go through Part One before reading further to see what issues can result from trying to implement Equatable conformance or even just equality comparisons for protocols. Even if you are familiar with these issues, it would be useful to glance through the sample code in Part One since the code in this post is based on the protocols and concrete types introduced there.

Contents

Self or associated type requirements
What is type erasure
Type erasure in action
Laying the groundwork for Equatable conformance
The elusive Equatable conformance
The test drive
Usage
Variation
Conclusion
Acknowledgements

Now that we have demonstrated (in Part One of this article) that it is not advisable and in some cases not even possible to implement equality for protocol types, let’s see if there is a way to address the issue. After all, we want to continue programming to abstractions rather than implementations, but we also want to be able to compare our abstract types for equality.

Self or associated type requirements

Let’s start by looking at the error we encountered when we tried to make our Fruit protocol conform to Equatable.

// error: protocol 'Fruit' can only be used as a generic constraint because it has Self or associated type requirements

We know all about the issues with having Self requirements from our experience with trying to conform to Equatable. But what are associated type requirements? The short answer is that associated types are used to make Swift protocols generic. This is a major topic and deserves its own post but the important point in this context is that protocols with associated types face the same issues that we encountered with Self requirements.

The good news is that in the case of protocols with associated types, the issue has largely been addressed through type erasure by creating a new concrete type that conforms to the protocol so can be used wherever a protocol type is expected. At the same time, it retains the generic character of the protocol.

What is type erasure

Type erasure, as the name suggests is a process by which a new type is created to encapsulate an instance of another type, to overcome some limitations of the original type and / or to enable client code to use the relevant features without having to deal with the specifics of the original type. The ‘relevant’ features would generally be determined by a protocol to which the original type conforms. The type eraser would also conform to the same protocol, implementing the requirements of the protocol and simply forwarding the operations to the encapsulated type. It is noteworthy that type erasure is not the same as casting, where the original type can be reclaimed simply by reversing the cast operation. In this case, the original type is completely encapsulated.

Type erasure is not a new concept. Swift has long had type erasers in the Standard Library. In fact, there is already a de facto naming convention that the Standard Library uses for type erasers, i.e., prefixing the name of the relevant protocol with ‘Any’. Examples from the Standard Library include AnySequence, AnyCollection, AnyHashable, etc. The purpose of these type erasers is to enable clients to use the desired functionality without having to deal with the specifics of the type being used. AnySequence, for instance, allows clients to use any type that conforms to the Sequence protocol without having to deal with the specifics of the underlying instance, which could be an array, a set, or a dictionary, among others.

What we are interested in is the other use case for type erasure, where it has been used to overcome the limitations of protocols with associated type requirements. This was demonstrated by Rob Napier in his talk at dotSwift 2016 and also in a post in his Cocoaphony blog.

Seems like a promising approach, so we forge ahead.

Type erasure in action

For our purposes, all we need is a simple wrapper type, a struct with a single initializer that takes one argument of the protocol type where conformance to Equatable is desired. The wrapper type would encapsulate the instance passed in through the constructor and all subsequent access to the methods and properties defined by the protocol would be through the methods and properties of the wrapper type, which would also conform to the protocol. We will simply save the instance passed in as a private property of the wrapper and use it to provide the required functionality to the wrapper type.

Methods called on the wrapper type would call the corresponding methods on the saved instance, passing any arguments and returning any values, as applicable. Computed properties would be similarly dealt with. For each stored property declared by the protocol, the wrapper type would have a computed property with a required get and an optional set block. For stored properties that are let constants, only the get block would be required, which would retrieve the value of the corresponding stored property of the stored instance. For var properties, a set block would also be required to set the value of the corresponding stored property of the wrapped instance.

Since the purpose of the exercise is to achieve Equatable conformance, it stands to reason that our wrapper types should only accept instances of concrete types that not only conform to the protocol in question but also conform to Equatable. Accordingly, and in keeping with the aforementioned naming convention for type erasers, we will use the prefix ‘Any’ and add the word ‘Equatable’. The general form for the names of such wrapper types would then be AnyEquatable<protocol name>.

Using the above approach, we create type erasing wrapper types for the two protocol types introduced in Part One of this post. 

struct AnyEquatableFruit: Fruit {
    init(_ fruit: Fruit) {
        self.fruit = fruit
    }
    
    var weight: Int {
        return fruit.weight
    }
    
    var grade: Int {
        return fruit.grade
    }
    
    private let fruit: Fruit
}

struct AnyEquatableShape: Shape {
    init(_ shape: Shape) {
        self.shape = shape
    }
    
    func draw() {
        shape.draw()
    }
    
    private let shape: Shape
}

As per our naming convention, we have called these types AnyEquatableFruit (for the Fruit protocol) and AnyEquatableShape (for the Shape protocol).

Laying the groundwork for Equatable conformance

Before we proceed to add Equatable conformance to our newly minted wrapper types, we need to make a small addition to the protocols themselves because we need a way to use the protocols to access the equality functions implemented for the conforming types. To achieve this, we declare a new isEqualTo() method in the protocol and provide a default implementation which only applies to conforming types that are Equatable. This will ensure that our wrapper types will only accept instances of concrete types that conform to Equatable. 

protocol Fruit {
    func isEqualTo(_ other: Fruit) -> Bool
    var weight: Int { get }
    var grade: Int { get }
}

extension Fruit where Self: Equatable {
    func isEqualTo(_ other: Fruit) -> Bool {
        guard let otherFruit = other as? Self else { return false }
        return self == otherFruit
    }
}

protocol Shape {
    func draw()
    func isEqualTo(_ other: Shape) -> Bool
}

extension Shape where Self: Equatable {
    func isEqualTo(_ other: Shape) -> Bool {
        guard let otherShape = other as? Self else { return false }
        return self == otherShape
    }
}

The isEqualTo(_:) method we have added does the following:

  1. The guard clause attempts to cast the instance passed in as the argument to the type represented by Self, which is the concrete type of the instance on which the method is called. If the cast fails, i.e., the instance being compared has a different concrete type, false is returned. This will ensure, for instance, that apples and oranges do not end up being equal.
  2. Once we are sure that the instance passed in as the argument has been successfully cast to the type of the instance on which the method has been called, the instance uses self (with a lowercase ‘s’) to compare itself for equality with the instance passed in as the argument. Since this extension only applies to concrete types that are also Equatable, the presence of an equality method is guaranteed.

The elusive Equatable conformance

Now for the piece de resistance — implementing Equatable conformance on our wrapper types. Since our wrapper types are structs and not protocols, there is no drama from the compiler and we are able to implement an equality function and Equatable conformance on both the wrapper types.

extension AnyEquatableFruit: Equatable {
    static func ==(lhs: AnyEquatableFruit, rhs: AnyEquatableFruit) -> Bool {
        return lhs.fruit.isEqualTo(rhs.fruit)
    }
}

extension AnyEquatableShape: Equatable {
    static func ==(lhs: AnyEquatableShape, rhs: AnyEquatableShape) -> Bool {
        return lhs.shape.isEqualTo(rhs.shape)
    }
}

The main point to note is that in each case the equality comparison is delegated to the underlying concrete type using the isEqualTo(_:) method already implemented on the protocol. This, as already explained, ensures that only instances of the same type can be considered equal and the equality function implemented on the underlying type is called, which can take into account all stored properties of the concrete type, not just those declared in the protocol (if any).

The test drive

First, we create some instances of our wrapper types which wrap instances of the corresponding concrete types.

let apple = AnyEquatableFruit(Apple(weight: 10, grade: 2))
let secondApple = AnyEquatableFruit(Apple(weight: 10, grade: 2))
let thirdApple = AnyEquatableFruit(Apple(weight: 15, grade: 2))
let orange = AnyEquatableFruit(Orange(weight: 10, grade: 2))

let appleFromAustralia = AnyEquatableFruit(ImportedApple(weight: 10, grade: 2, countryOfOrigin: "Australia"))
let appleFromSouthAfrica = AnyEquatableFruit(ImportedApple(weight: 10, grade: 2, countryOfOrigin: "South Africa"))

let rectangle = AnyEquatableShape(Rectangle(topLeftCorner: CGPoint(x: 5.0, y: 4.0), length: 10.0, width: 7.0))
let secondRectangle = AnyEquatableShape(Rectangle(topLeftCorner: CGPoint(x: 5.0, y: 4.0), length: 10.0, width: 7.0))
let thirdRectangle = AnyEquatableShape(Rectangle(topLeftCorner: CGPoint(x: 6.0, y: 4.0), length: 10.0, width: 7.0))
let circle = AnyEquatableShape(Circle(centre: CGPoint(x: 6.0, y: 8.0), radius: 10.0))

Note: If you feel the syntax above is a bit verbose, hold on to that thought. A more concise way to create wrapper types is presented in the Usage section just coming up.

Next we run equality tests and validate the results.

print(apple == secondApple)                         // true
print(apple == thirdApple)                          // false
print(apple == orange)                              // false

print(appleFromAustralia == appleFromSouthAfrica)   // false

print(rectangle == secondRectangle)                 // true
print(rectangle == thirdRectangle)                  // false
print(rectangle == circle)                          // false

All the equality comparisons return the expected results. It is pertinent to note that our new approach has fixed the issues we had encountered when trying to implement equality functions directly on the protocols.

To make sure that we can use our wrapper types where the corresponding types are expected, we assign a couple of wrapper types to variables of the protocol types.

let someFruit: Fruit = orange
let someShape: Shape = circle

We also need to make sure that our wrapper type will work in situations where Equatable conformance is expected. 

func equatableExpecter<T: Equatable>(_ first: T, _ second: T) -> Bool {
    return first == second
}

print(equatableExpecter(apple, secondApple))    // true
print(equatableExpecter(rectangle, circle))     // false

We have created a function which takes two types that conform to Equatable. We then passed instances of our wrapper types to this function and checked the results to make sure things work as expected.

Usage

Since our wrapper types conform to the corresponding protocol, they can be used wherever the corresponding protocol type is expected. However, in actual usage, we would expect to use protocol types as we would normally and create wrapper types only for situations where Equatable conformance is required. To make this easier, we can add a convenience asEquatable() method to the protocol to enable wrapping without having to call the initializer of the wrapper type.

This is demonstrated below for the Fruit protocol.

protocol Fruit {
    func asEquatable() -> AnyEquatableFruit
    func isEqualTo(_ other: Fruit) -> Bool
    var weight: Int { get }
    var grade: Int { get }
}

extension Fruit where Self: Equatable {
    func asEquatable() -> AnyEquatableFruit {
        return AnyEquatableFruit(self)
    }
    
    func isEqualTo(_ other: Fruit) -> Bool {
        guard let otherFruit = other as? Self else { return false }
        return self == otherFruit
    }
}

Let’s say we have some arrays of type Fruit.

let first: [Fruit] = [apple, orange, appleFromAustralia]
let second: [Fruit] = [apple, orange, secondApple]
let third: [Fruit] = [apple, orange, appleFromAustralia]

We can compare these arrays for equality by mapping them to arrays of the corresponding wrapper types and then invoking the equality function.

print(first.map({ $0.asEquatable() }) == second.map({ $0.asEquatable() }))    // false
print(first.map({ $0.asEquatable() }) == third.map({ $0.asEquatable() }))     // true

In the example above, we have created instances of the wrapper types only for the purpose of one equality comparison. We could also save the wrapper type instances if we foresee the need for repeated use. Since each wrapper type conforms to the corresponding protocol, instances of the wrapper type can freely be used wherever the corresponding protocol type is expected.

Variation

There are important semantic differences between value and reference types that determine when and how they should be used in application design. The approach presented above works for structs, which is a reasonable assumption since structs are value types characterized by attribute-based equality and they should always conform to Equatable. Classes, on the other hand, are reference types and should be used to model domain entities that have identity and a life cycle. Applying attribute-based equality to class instances may lead to erroneous results. This is why implementing Equatable conformance for classes may not be straightforward and is generally not advisable.

If, however, you do find yourself working with protocols and conforming classes that also conform to Equatable, you may have to use a modified version of the isEqualTo(_:) method presented above. This will be required when the two types being compared are a class and its subclass. For the Fruit protocol example, this would be the case, for instance, when Apple is a class and ImportedApple is its subclass. In such a scenario, the standard isEqualTo(_:) method, which simply checks whether one type can be cast to another, will produce incorrect results, as shown below.

class Apple: Fruit, Equatable { ... }
class ImportedApple: Apple { ... }

let apple: Fruit = Apple(weight: 10, grade: 5)
let importedApple: Fruit = ImportedApple(weight: 10, grade: 5, countryOfOrigin: "Australia")

print(apple.isEqualTo(importedApple))   // true
print(importedApple.isEqualTo(apple))   // true

This is because of the subtle change to Self when dealing with a class and its subclass(es). When a method is called on an instance typed as a protocol, Self represents the concrete type that conforms to the protocol. Normally, this would also be the concrete type of the instance on which the protocol method is called, i.e., the type of self. However, when we call a protocol method on an instance of a subclass whose superclass conforms to the protocol, the type of self is the subclass type but Self represents the superclass type.

This means that the otherFruit = other as? Self conditional cast in the isEqualTo(_:) method would become otherFruit = other as? Apple, regardless of whether the method is called on an instance of Apple or ImportedApple. The isEqualTo(_:) method will, therefore, return true in both cases as long as both the instances have equal values for the weight and grade properties, ignoring the countryOfOrigin property.

This can be remedied by modifying the guard clause in isEqualTo(_:) to include an explicit check that the concrete type of other is the same as the type of the instance on which the method has been called, proceeding to the cast operation only if the concrete types are the same. The modified isEqualTo(_:) method will have to be implemented in each class and subclass.

The isEqualTo(_:) method in Apple would be as follows. 

func isEqualTo(_ other: Fruit) -> Bool {
    guard type(of: other) == Apple.self, let otherFruit = other as? Apple else { return false }
    return self == otherFruit
}

In ImportedApple, it would be as below.

override func isEqualTo(_ other: Fruit) -> Bool {
    guard type(of: other) == ImportedApple.self, let otherFruit = other as? ImportedApple else { return false }
    return self == otherFruit
}

With the modified isEqualTo(_:) methods implemented in the classes, we get the correct result and normal service resumes.

print(apple.isEqualTo(importedApple))   // false
print(importedApple.isEqualTo(apple))   // false

It is noteworthy that the test for type equality is required in the isEqualTo(_:) method in Apple. Without it, a comparison between an instance of Apple and an instance of ImportedApple would break symmetry. This is because a conditional cast to Apple would succeed when other is an instance of ImportedApple but the reverse would not be true. This would be the case for an instance of any class when other is an instance of its subclass. A test for type equality is not actually required in the isEqualTo(_:) method in ImportedApple since it does not have any subclasses. However, it is prudent to implement the method with the type equality test in all classes, in case we subclass any of them at a later stage.

Conclusion

In Part One of this article, we demonstrated how making protocols conform to Equatable renders us unable to use the protocols as types and why trying to implement equality functions on protocols, even without Equatable conformance, can lead to erroneous results in some cases and is impossible in others.

In this part, we have walked though an alternate approach to addressing the issue, using type erasure by creating wrapper types that conform to the corresponding protocol and also conform to Equatable. The equality function we implemented on our wrapper types returns false if the underlying concrete types of the instances being compared are not the same and, given two instances of the same concrete type, it delegates the equality comparison to the concrete type. This allows us to program to abstractions using protocol types while being able to safely make equality comparisons at the protocol level and also use functionality provided by the Swift Standard Library which is available only to types that conform to Equatable.

Acknowledgements

Thanks to:

  • Rob Napier for the original work on using type erasure for protocols with associated types.
  • Stephane Philipakis for suggesting the name asEquatable() for the convenience methods that enable wrapping without having to call the initializer of the wrapper type.
  • Heath Borders for pointing out the potential problem with the isEqualTo(_:) method when dealing with class instances. This led to addition of the Variation section in this article.

Swift Protocols Don’t Play Nice With Equatable. Or Can They? (Part One)

*** Updated for Swift 4.1 ***

This is Part One of a two-part article. This part demonstrates how making protocols conform to Equatable renders us unable to use the protocols as types and why trying to implement equality functions on protocols, even without Equatable conformance, can lead to erroneous results in some cases and is impossible in others.

Part Two uses type erasure to implement equality comparisons and Equatable conformance at the protocol level. This allows us to program to abstractions using protocol types while being able to safely make equality comparisons and also use functionality provided by the Swift Standard Library which is available only to types that conform to Equatable.

Contents

Fruit, anyone?
Programming to interfaces, not implementations
Protocols with Self requirement
Compromises, compromises
Does this really make sense!
Protocols are meant to be about behavior, aren’t they?
Conclusion

In a landmark WWDC 2015 talk titled “Protocol-oriented Programming in Swift” a.k.a. “the Crusty talk”, Dave Abrahams declared that Swift is a Protocol-oriented programming language. I would leave the details of how this differs from traditional object-oriented programming for another post. In essence, this entails using protocols to represent abstractions and favouring value types over reference types, unless the entity you are modeling specifically requires reference semantics.

Another piece of advice that came along with this new paradigm is to make all value types Equatable, or to be more exact, conform to the Equatable protocol. This makes sense as the concept of attribute-based equality is one of the defining characteristics of values, as we see for values we commonly use such as integers, decimals, strings, etc.

Fruit, anyone?

Let’s say we are working in a domain dealing with fruit. To keep things simple, let’s say that each piece of fruit has two characteristics, its weight and grade, both integer values. To keep things nice and abstract and to avoid having to deal directly with concrete types, we declare a protocol.

protocol Fruit {
    var weight: Int { get }
    var grade: Int { get }
}

Next we declare two concrete types representing apples and oranges respectively, both conforming to our protocol.

struct Apple: Fruit, Equatable {
    let weight: Int
    let grade: Int
}

struct Orange: Fruit, Equatable {
    let weight: Int
    let grade: Int
}

Note that we have also declared Equatable conformance for both our concrete types. This means that any two apples or oranges having equal weights and grades will be considered equal.

Programming to interfaces, not implementations

This age-old advice originated in the world of object-oriented programming and applies equally in the protocol-oriented realm. This is good programming practice in that it makes code more flexible, extensible and less brittle. The consequence of programming to interfaces is that most of our code would deal in abstract fruits, rather than concrete apples and oranges.

func doSomethingWithFruit(fruit: Fruit) {}
var storeFruit: [Fruit] = []

The actual creation of concrete instances would presumably be handled by factory methods which return the instances typed as Fruit so we can happily program to the abstraction rather than worrying about which concrete type of fruit we are dealing with.

At some point, though, we are going to have to compare two instances for equality. Now, both our concrete types implement Equatable, so had we been dealing with the concrete types, comparing for equality would have been a cinch. However, what we are dealing with are instances typed as Fruit.

No sweat. We will simply implement an equality function for our protocol and modify our protocol definition to add conformance with Equatable.

protocol Fruit: Equatable {
    var weight: Int { get }
    var grade: Int { get }
}

func ==(lhs: Fruit, rhs: Fruit) -> Bool {
    return lhs.weight == rhs.weight && lhs.grade == rhs.grade
}

It is noteworthy that, unlike concrete types, protocols do not automatically synthesize Equatable conformance by simply declaring it in the protocol definition. This should perhaps be the first hint that this is not something we should be doing.

Protocols with Self requirement

Sure enough, the moment we add Equatable conformance to our protocol, things start to go awry. All our functions, arrays, etc., that use the Fruit protocol as a type show the following error:

error: protocol 'Fruit' can only be used as a generic constraint because it has Self or associated type requirements

This error looks rather cryptic at first, but becomes easy to understand once we inspect the requirements of the Equatable protocol at bit more closely.

static func ==(Self, Self)

Self in the above method signature refers to the concrete type of the actual instances being compared and means that the concrete type of both the arguments must be the same. This is okay for structs or classes but cannot be guaranteed for protocols since there could be any number of concrete types which may adopt a given protocol and we cannot guarantee that any two instances being compared will always have the same concrete type. Swift deals with this issue by ensuring that any protocol that conforms to Equatable can no longer be used as a type.

Compromises, compromises

Now we are at an impasse. We either let go of Equatable conformance for our protocol or we will not be able to use our protocol as a type.

Equatable conformance is important to have because a host of functionality provided by the Swift Standard Library relies on Equatable conformance. For instance:

  1. If we want to check two arrays for equality, their elements need to conform to Equatable. The same is true if we want to check whether an array contains a given value, without having to provide a closure to determine equivalence.
  2. The Comparable protocol, used to sort elements of a collection, inherits from Equatable.
  3. The Hashable protocol, to which keys of a Dictionary and members of a Set must conform, inherits from Equatable.

Having said that, the main benefit of working with protocols is that they allow us to create behavior-rich abstractions that can make our code more decoupled and more easily extensible. Therefore, inability to use our protocol as a type is a show-stopper. So we bite the bullet and remove Equatable conformance from our protocol. This gets rid of the errors and we get to keep our equality function. We also add a function to ensure that we can compare any two instances types as Fruit for inequality.

func !=(lhs: Fruit, rhs: Fruit) -> Bool {
    return !(lhs == rhs)
}

Note that an inequality function gets synthesized automatically for types that conform to Equatable.

Does this really make sense!

Armed with our equality function, we do some testing.

let apple: Fruit = Apple(weight: 10, grade: 2)
let secondApple: Fruit = Apple(weight: 10, grade: 2)
let thirdApple: Fruit = Apple(weight: 15, grade: 2)
let orange: Fruit = Orange(weight: 10, grade: 2)

print(apple == secondApple) // true
print(apple == thirdApple)  // false
print(apple == orange)      // true

The first two results are expected but the third literally equates apples and oranges! This is because the equality method of the protocol is simply checking the values of the properties weight and grade regardless of the concrete types of the instances being compared. We could use generics to ensure that only instances of the same type can be compared for equality.

func ==<T: Fruit>(lhs: T, rhs: T) -> Bool {
    return lhs.weight == rhs.weight && lhs.grade == rhs.grade
}

But this does not help as it can only be used to compare for equality instances of types that conform to protocol Fruit, not instances typed as Fruit. Instead, we can solve the problem of comparing apples with oranges by modifying the equality function presented earlier to add a guard clause.

func ==(lhs: Fruit, rhs: Fruit) -> Bool {
    guard type(of: lhs) == type(of: rhs) else { return false }
    return lhs.weight == rhs.weight && lhs.grade == rhs.grade
}

Not very elegant, but at least now apples are no longer equal to oranges.

print(apple == orange)      // false

Let’s assume that we now have to cater not just to apples sourced locally but also to apples imported from other countries. So we add a new type to represent imported apples which has a property to identify the country of origin. Imported or not, apples are fruit so our new type also conforms to the Fruit protocol.

struct ImportedApple: Fruit, Equatable {
    let weight: Int
    let grade: Int
    let countryOfOrigin: String
}

Note that the automatically synthesized Equatable conformance for ImportedApple will take into account the country of origin in addition to the weight and grade. This will ensure, for instance, that apples imported from Australia do not end up being equal to those imported from South Africa.

However, when we have imported apples typed as Fruit, which is the likely scenario since we prefer to write code in terms of abstractions, we would have the following result.

let appleFromAustralia: Fruit = ImportedApple(weight: 10, grade: 2, countryOfOrigin: "Australia")
let appleFromSouthAfrica: Fruit = ImportedApple(weight: 10, grade: 2, countryOfOrigin: "South Africa")

print(appleFromAustralia == appleFromSouthAfrica)  // true

This illustrates just one one way in which adding a new concrete type which conforms to the same protocol but adds a type-specific property could lead to erroneous results being given by the equality function written in terms of the protocol type. And this is just a trivial example. In a domain of any complexity, it would be difficult to keep track of or even to anticipate all the errors that may be introduced by protocol-level equality comparisons.

Protocols are meant to be about behavior, aren’t they?

Yes, they are. Protocols are the tools for building rich behavioural abstractions, leaving implementation details to the concrete conforming types. Therefore, it is common to find protocols that only declare methods and no properties.

Here is an example of a protocol representing a shape that knows how to draw itself. The protocol does not say anything about what the shape should be or what data conforming types may store to be able to draw themselves, only that types that conform must implement a method to draw themselves.

protocol Shape {
    func draw()
}

Any type representing a shape that knows how to draw itself can conform to this protocol. To illustrate, we create two concrete types, one representing a rectangle and the other representing a circle.

struct Rectangle: Shape, Equatable {
    func draw() { ... }
    
    let topLeftCorner: CGPoint
    let length: Double
    let width: Double
}

struct Circle: Shape, Equatable {
    func draw() { ... }
    
    let centre: CGPoint
    let radius: Double
}

Now then, how do we apply a protocol-level equality comparison when the protocol does not declare any properties? The short answer is that we can’t. Each conforming type can be Equatable (in fact both our concrete types are) but we don’t have a way of checking equality at the level of the protocol since the protocol does not declare any properties.

Conclusion

Having worked through these examples and seen that trying to implement equality for protocols is fraught with possibilities of errors in some cases and just not possible in others, we can appreciate why protocols that are to be used as types cannot conform to Equatable. We could work around this limitation by sacrificing Equatable conformance in favour of a simple equality function, but it would likely produce correct results only under carefully controlled conditions and cannot be trusted to work correctly in real-world domains. Besides, this approach completely falls apart in cases where the protocol does not declare any properties.

This concludes Part One of this article. Do check out Part Two, which uses type erasure to implement equality comparisons and Equatable conformance at the protocol level. This allows us to program to abstractions using protocol types while being able to safely make equality comparisons and also use functionality provided by the Swift Standard Library which is available only to types that conform to Equatable.