From the blog

Protocol Extensions in Swift 2.0

At this year’s WWDC, Swift 2.0 featured prominently. The announcement of Apple’s plans to make Swift open source grabbed plenty of attention, but the most exciting change to the language itself has to be protocol extensions.

What are Protocol Extensions?

In Objective-C (and in Swift prior to 2.0) protocols contain only method and property declarations. This is fine, but it requires each class or struct conforming to the interface to provide its own complete implementation.

Swift 2.0 greatly expands the reach of protocols. Now, any existing protocol can be extended with additional methods. Furthermore, protocol extensions in Swift 2.0 can now contain a default implementation that conforming classes and structs can access for free.

Adding Functionality

Swift’s built-in protocols provide common functionality over some of our favorite classes. Take CollectionType, for example. CollectionType provides the map function to Array, ArraySlice, Dictionary, and Set, just to name a few.

What if we wanted everything with the ability to map to also be able to shuffle? Prior to Swift 2.0, this would mean writing a new protocol containing a shuffle method and adding separate implementations to each conforming class or struct. Depending on how far we wanted to go with it, we could end up duplicating code across a number of classes.

protocol Shuffler {
    func shuffle<T>()
}

extension Array: Shuffler {
    func shuffle<T>() {
        ...
    }
}

extension Dictionary: Shuffler {
    func shuffle<T>() {
        ...
    }
}

extension Set: Shuffler {
    func shuffle<T>() {
        ...
    }
}

Swift 2.0 allows us to simply do this:

extension CollectionType {
    func shuffle<T>()
}

When we extend CollectionType, all of our favorite collections gain the ability to shuffle.

Default Implementations

It is often the case that a method defined in a protocol will have the same implementation across most of its conforming classes and structs. Before Swift 2.0, this meant writing identical method implementations in two or more classes.

Swift 2.0 allows method implementations to be specified in protocol extensions, like so:

extension CollectionType {
    func shuffle() -> [Self.Generator.Element] {
        return sort(){ lhs, rhs in
            return arc4random() < arc4random()
        }
    }
}

The default implementation can be overriden, but every class or struct that conforms to the interface gets it free-of-charge.

The Big Picture

Protocol extensions don’t change the ball game in a substantial way, but they certainly represent a welcome language feature. It’s not uncommon to need a new piece of functionality that applies to all types conforming to an interface. We’ve always been able to meet this need. But in the past, it required touching a number of classes and writing individual – potentially duplicative – implementations. Now we can solve the same problem in a low-impact manner by using protocol extensions.

To find out more about Swift 2.0, check out these talks from WWDC 2015:

What’s New in Swift

Protocol-Oriented Programming in Swift


Interested in joining the Raizlabs team making great software? We’re hiring developers in Boston and SF.


2 Comments

  1. @Murray Sagal if you conform a type to a protocol, and implement a method from that protocol, and then call that method on an instance of that type, that implementation will take precedence over the implementation in a protocol extension.

Leave a Reply

Your email address will not be published. Required fields are marked *