Here, the idea is that we take one of the types that already implement Equatable in a proper way (i.e. Int, String, …) and add a new property requirement to our Bookmarkable protocol. Then, we can use this property to add Equatable support without actually implementing Equatable:

protocol Bookmarkable {
    var identifier: Int { get }
}

struct Bookmark: Bookmarkable {
    var identifier: Int
}

var myBookmarks: [Bookmarkable] = []

The main change, compared to the code above, is that the var identifier moved to the Bookmarkable protocol and that we removed the func ==.

While this works better, it still has a major deficit. Since Bookmarkable does not directly comply with Equatable, you will not gain the standard library's methods that specifically deal with Equatable types. So instead of being able to call Array.contains like this:

let ourBookmark = Bookmark(identifier: 0)
let result = myBookmarks.contains(ourBookmark)

You will have to use the more verbose closure-based version:

let ourBookmark = Bookmark(identifier: 0)

let result = myBookmarks.contains { (bookmark) -> Bool in
    return bookmark.identifier == ourBookmark.identifier
}

Quite often, when Swift's associated types are dicussed, type erasure is mentioned as another solution to the problem of handling the issues that associated types bring along.

Type Erasure in the context of associated types solves one particular problem. We'll use computers as an example. Back in the golden age of desktop operating systems, you could buy a desktop computer with many non-X86 CPU architectures: PowerPC, Alpha, Sparc, 68000, and so on. One of the many differences were the endianness of the architecture. Lets model these computers in Swift:

protocol CPU {
    var littleEndian: Bool { get }
}

struct PowerPC: CPU {
    let littleEndian = false
}

struct X86: CPU {
    let littleEndian = true
}

Next up, we want to define a protocol for a computer. It could be a desktop computer or a phone or maybe a game console, so we use a protocol. In order to model the CPU, we're using an associated type, so that the actual type can define the CPU:

protocol Computer {
    associatedtype ProcessorType: CPU
    var processor: ProcessorType { get }
    var processorCount: Int { get }
}

Based on this, we can now define a couple of systems:

struct PowerMacG5: Computer {
    let processor = PowerPC()
    let processorCount = 2
}

struct Xbox360: Computer {
    let processor = PowerPC()
    let processorCount = 1
}

struct MacPro: Computer {
    let processor = X86()
    let processorCount = 1
}

Now that we have all this, we'd like to perform a computation on all PowerPC based computers. I.e. something like:

let powerComputers = [PowerMacG5(), Xbox360()]

However, what would be the type of this? We can't use the Computer protocol, as it contains associated types. However, the associated types for the PowerMacG5 and the Xbox360 are the same, so in terms of types, Swift ought to understand that those things are kinda similar. However, there's no way to (easily) express this in the type system; both PowerMacG5 and Xbox360 are not the correct types for the array:

// None of those work
let powerComputers: [PowerMacG5] = [PowerMacG5(), Xbox360]
let powerComputers: [Xbox360] = [PowerMacG5(), Xbox360]
let powerComputers: [Computer] = [PowerMacG5(), Xbox360]

Type erasure is a solution for this. The idea is to box the actual type into a generic wrapper so that Swift can coalesce around wrapper + type. The solution we're aiming for would look like this in the end:

let powerComputers: [AnyComputer<PowerPC>] = [AnyComputer(PowerMacG5()), AnyComputer(Xbox360())]

Now we would have our shared type, in this case it is AnyComputer<CPU>. Where does this mystic AnyComputer come from? We have to build it ourselves. This is a multi-step process, and requires quite a bit of boilerplate. We will start simple and expand step by step. This solution requires multiple types.

In essense, what we're going to build, is a generic wrapper (or box) that hosts a type conforming to a protocol with an associated type. It does so by implementing the requirements of the protocol and forwarding all invocations to the boxed type.

The first new type we need for that is a base class that acts as a abstract class:

class AnyComputerBase<Processor: CPU>: Computer {
    var processor: Processor {
	fatalError()
    }
    var processorCount: Int {
	fatalError()
    }
}

This class should never be initialized, as it only provides an abstract template of what subclasses should implement. While other languages (like Java) allow explicitly marking classes as abstract, Swift doesn't offer us a way to do so. One solution to this is adding a fileprivate init to this class. However as that requires subclasses to be in the same file as this superclass, we can also just make the whole class private with an even better result. Now, other parts of the code won't even know about the existence of AnyComputerBase or even initialize it:

private class AnyComputerBase<Processor: CPU>: Computer {
...
}

Why do we even need this, and what does it do? As you can see, it just implements the Computer protocol by implementing the requirements and doing nothing in there. The more important part is that it moves the associated type from the protocol into a generic type for the class: AnyComputerBase<Processor: CPU>.

Swift automatically figures out that Processor is the typealias for Computer.ProcessorType. However, when in doubt you can also add an extra typealias:

class AnyComputerBase<Processor: CPU>: Computer {
  typealias ProcessorType = Processor
  ...
}

The next step is the most difficult to understand part of type erasure, which means that after this, it'll be easy. We will introduce another private type. This will be the actual box that houses our original type (the XBox360 or the PowerMac G5). Let's start by having a look at the code:

private class AnyComputerBox<ConcreteComputer: Computer>: 
	AnyComputerBase<ConcreteComputer.ProcessorType> 
{
    private let internalComputer: ConcreteComputer
    override var processor: ConcreteComputer.ProcessorType {
	return internalComputer.processor
    }
    override var processorCount: Int {
	return internalComputer.processorCount
    }
    init(_ computer: ConcreteComputer) {
	internalComputer = computer
    }
}

The most important concept here can be found in the very first line:

private class AnyComputerBox<ConcreteComputer: Computer>: 
	AnyComputerBase<ConcreteComputer.ProcessorType>

Here, we define a new type AnyComputerBox which is generic over any computer (ConcreteComputer). This new type, then, is a subclass of our earlier abstract class AnyComputerBase. Remember that AnyComputerBase made the original ProcessorType of the Computer protocol generic by adding it as a generic parameter CPU. Now, our new box has a different generic type (Computer) and provides only its associated type ProcessorType to the abstract superclass. In a simpler explanation, this is what happens (in a mock language):

1. Computer<CPU>
2. AnyComputerBase<Processor: CPU>: Computer<CPU> where Computer.CPU = Processor
3. AnyComputerBox<ConcreteComputer: Computer>: AnyComputerBase<ConcreteComputer.ProcessorType>

So the box (AnyComputerBox) subclasses the abstract class and forwards in the Processor type via its own generic Computer type which also has a ProcessorType.

Why do we do this? It makes the box generic over any computer so that any computer can be boxed into it.

The rest of the class is simple. There's an internal computer internalComputer which is the actual type conforming to the Computer protocol. We're also overriding the two classes that are required by the protocol and forwarding the implementations of the internalComputer. Finally we have an initializer with a new ConcreteComputer (i.e. the Computer protocol).

In the next and final step, we're building the actual type that will be used as the proverbial type eraser. Just as before, lets have a look at the code first:

final class AnyComputer<Processor: CPU>: Computer {
    private let box: AnyComputerBase<Processor>
    var processor: Processor {
	return box.processor
    }
    var processorCount: Int {
	return box.processorCount
    }
    init<Concrete: Computer>(_ computer: Concrete) 
	where Concrete.ProcessorType == Processor {
      box = AnyComputerBox(computer)
    }
}

This AnyComputer conforms to the Computer protocol and is generic over the CPU type that the protocol requires. Once again, we implement the protocol requirements (processor, and processorCount) and forward to a boxed type. This time we're forwarding to private let box: AnyComputerBase<Processor>. This box is set in the initializer where most of the magic happens:

init<Concrete: Computer>(_ computer: Concrete) 
    where Concrete.ProcessorType == Processor {
  box = AnyComputerBox(computer)
}

The problem with protocols with associated types is that you can't use them as property types. Here, init requires any type conforming to the Computer protocol. This is done by having a method-generic type Concrete that requires Computer conformance. Even more, we also add a constraint that makes sure that the generic Processor type of the new AnyComputer class is the same type as the associated type of the Concrete Computer type.

And now comes the kicker: Since we cannot set a property as being of type Computer we, instead, have a property that is of AnyComputerBase with a generic type for the Processor. As our AnyComputerBox type is a subclass of AnyComputerBase we can literally put any box (that is a subclass of AnyComputerBase into this property. In this case, we're creating a new box with the Concrete Computer.

Then we return the implementations of the contents of the box (i.e. the actual Concrete Computer) in our Computer implementations:

var processorCount: Int {
    return box.processorCount
}

With all this machinery in place, we can finally use this in order to have different types (which share an associated type) in one container:

let powerComputers: [AnyComputer<PowerPC>] = 
    [AnyComputer(PowerMacG5()), AnyComputer(Xbox360())]