About Protocols

A Protocol specifies initialisers, properties, functions, subscripts and associated types required of a Swift object type (class, struct or enum) conforming to the protocol. In some languages similar ideas for requirement specifications of subsequent objects are known as ‘interfaces’.

A declared and defined Protocol is a Type, in and of itself, with a signature of its stated requirements, somewhat similar to the manner in which Swift Functions are a Type based on their signature of parameters and returns.

Swift Protocol specifications can be optional, explicitly required and/or given default implementations via a facility known as Protocol Extensions. A Swift Object Type (class, struct or enum) desiring to conform to a Protocol that’s fleshed out with Extensions for all its specified requirements needs only state its desire to conform to be in full conformance. The default implementations facility of Protocol Extensions can suffice to fulfil all obligations of conforming to a Protocol.

Protocols can be inherited by other Protocols. This, in conjunction with Protocol Extensions, means Protocols can and should be thought of as a significant feature of Swift.

Protocols and Extensions are important to realising Swift’s broader objectives and approaches to program design flexibility and development processes. The primary stated purpose of Swift’s Protocol and Extension capability is facilitation of compositional design in program architecture and development. This is referred to as Protocol Oriented Programming. Crusty old timers consider this superior to a focus on OOP design.

Protocols (opens new window) define interfaces which can be implemented by any struct (opens new window), class (opens new window), or enum (opens new window):

protocol MyProtocol {
    init(value: Int)                      // required initializer
    func doSomething() -> Bool            // instance method
    var message: String { get }           // instance read-only property
    var value: Int { get set }            // read-write instance property
    subscript(index: Int) -> Int { get }  // instance subscript
    static func instructions() -> String  // static method
    static var max: Int { get }           // static read-only property
    static var total: Int { get set }     // read-write static property
}

Properties defined in protocols (opens new window) must either be annotated as { get } or { get set }. { get } means that the property must be gettable, and therefore it can be implemented as any kind of property. { get set } means that the property must be settable as well as gettable.

A struct, class, or enum may conform to a protocol:

struct MyStruct **: MyProtocol** {
    // Implement the protocol's requirements here
}
class MyClass **: MyProtocol** {
    // Implement the protocol's requirements here
}
enum MyEnum **: MyProtocol** {
    case caseA, caseB, caseC
    // Implement the protocol's requirements here
}

A protocol may also define a default implementation for any of its requirements through an extension (opens new window):

extension MyProtocol {
    
    // default implementation of doSomething() -> Bool
    // conforming types will use this implementation if they don't define their own
    func doSomething() -> Bool {
        print("do something!")
        return true
    }
}

A protocol can be used as a type, provided it doesn't have associatedtype requirements (opens new window):

func doStuff(object: **MyProtocol**) {
    // All of MyProtocol's requirements are available on the object
    print(object.message)
    print(object.doSomething())
}

let items : [**MyProtocol**] = [MyStruct(), MyClass(), MyEnum.caseA]

You may also define an abstract type that conforms to multiple protocols:

With Swift 3 or better, this is done by separating the list of protocols with an ampersand (&):

func doStuff(object: **MyProtocol & AnotherProtocol**) {
    // ...
}

let items : [**MyProtocol & AnotherProtocol**] = [MyStruct(), MyClass(), MyEnum.caseA]

Older versions have syntax protocol<...> where the protocols are a comma-separated list between the angle brackets <>.

protocol AnotherProtocol {
    func doSomethingElse()
}

func doStuff(object: **protocol<MyProtocol, AnotherProtocol>**) {
    
    // All of MyProtocol & AnotherProtocol's requirements are available on the object
    print(object.message)
    object.doSomethingElse()
}

// MyStruct, MyClass & MyEnum must now conform to both MyProtocol & AnotherProtocol
let items : [**protocol<MyProtocol, AnotherProtocol>**] = [MyStruct(), MyClass(), MyEnum.caseA]

Existing types can be extended to conform to a protocol:

extension String : MyProtocol {
    // Implement any requirements which String doesn't already satisfy
}

A delegate is a common design pattern used in Cocoa and CocoaTouch frameworks, where one class delegates responsibility for implementing some functionality to another. This follows a principle of separation of concerns, where the framework class implements generic functionality while a separate delegate instance implements the specific use case.

Another way to look into delegate pattern is in terms of object communication. Objects often needs to talks to each other and to do so an object need conform to a protocol in order to become a delegate of another Object. Once this setup has been done, the other object talks back to its delegates when interesting things happens.

For example, A view in userinterface to display a list of data should be responsible only for the logic of how data is displayed, not for deciding what data should be displayed.

Let's dive into a more concrete example. if you have two classes, a parent and a child:

class Parent { }
class Child { }

And you want to notify the parent of a change from the child.

In Swift, delegates are implemented using a protocol (opens new window) declaration and so we will declare a protocol which the delegate will implement. Here delegate is the parent object.

protocol ChildDelegate: class {
    func childDidSomething()
}

The child needs to declare a property to store the reference to the delegate:

class Child {
    weak var delegate: ChildDelegate?
}

Notice the variable delegate is an optional and the protocol ChildDelegate is marked to be only implemented by class type (without this the delegate variable can't be declared as a weak reference avoiding any retain cycle. This means that if the delegate variable is no longer referenced anywhere else, it will be released). This is so the parent class only registers the delegate when it is needed and available.

Also in order to mark our delegate as weak we must constrain our ChildDelegate protocol to reference types by adding class keyword in protocol declaration.

In this example, when the child does something and needs to notify its parent, the child will call:

delegate?.childDidSomething()

If the delegate has been defined, the delegate will be notified that the child has done something.

The parent class will need to extend the ChildDelegate protocol to be able to respond to its actions. This can be done directly on the parent class:

class Parent: ChildDelegate {
    ...

    func childDidSomething() {
        print("Yay!")
    }
}

Or using an extension:

extension Parent: ChildDelegate {
    func childDidSomething() {
        print("Yay!")
    }
}

The parent also needs to tell the child that it is the child's delegate:

// In the parent
let child = Child()
child.delegate = self

By default a Swift protocol does not allow an optional function be implemented. These can only be specified if your protocol is marked with the @objc attribute and the optional modifier.

For example UITableView implements the generic behavior of a table view in iOS, but the user must implement two delegate classes called UITableViewDelegate and UITableViewDataSource that implement how the specific cells look like and behave.

class MyViewController : UIViewController, UITableViewDelegate

Any methods not marked optional in the protocol definition (UITableViewDelegate in this case) must be implemented.

Protocols may define associated type requirements using the associatedtype keyword:

protocol Container {
    **associatedtype Element**
    var count: Int { get }
    subscript(index: Int) -> Element { get set }
}

Protocols with associated type requirements can only be used as generic (opens new window) constraints:

// These are **NOT allowed**, because Container has associated type requirements:
func displayValues(container: Container) { ... }
class MyClass { let container: Container }
// > error: protocol 'Container' can only be used as a generic constraint
// > because it has Self or associated type requirements

// These are allowed:
func displayValues**<T: Container>**(container: **T**) { ... }
class MyClass**<T: Container>** { let container: **T** }

A type which conforms to the protocol may satisfy an associatedtype requirement implicitly, by providing a given type where the protocol expects the associatedtype to appear:

struct ContainerOfOne<T>: Container {
    let count = 1          // satisfy the count requirement
    var value: T
    
    // satisfy the subscript associatedtype requirement implicitly,
    // by defining the subscript assignment/return type as T
    // therefore Swift will infer that T == Element
    subscript(index: Int) -> **T** {
        get {
            precondition(index == 0)
            return value
        }
        set {
            precondition(index == 0)
            value = newValue
        }
    }
}

let container = ContainerOfOne(value: "Hello")

^{(Note that to add clarity to this example, the generic placeholder type is named T – a more suitable name would be Element, which would shadow the protocol's associatedtype Element. The compiler will still infer that the generic placeholder Element is used to satisfy the associatedtype Element requirement.)}

An associatedtype may also be satisfied explicitly through the use of a typealias:

struct ContainerOfOne<T>: Container {

    **typealias Element = T**
    subscript(index: Int) -> **Element** { ... }

    // ...
}

The same goes for extensions:

// Expose an 8-bit integer as a collection of boolean values (one for each bit).
extension UInt8: Container {

    // as noted above, this typealias can be inferred
    typealias Element = Bool

    var count: Int { return 8 }
    subscript(index: Int) -> Bool {
        get {
            precondition(0 <= index && index < 8)
            return self & 1 << UInt8(index) != 0
        }
        set {
            precondition(0 <= index && index < 8)
            if newValue {
                self |= 1 << UInt8(index)
            } else {
                self &= ~(1 << UInt8(index))
            }
        }
    }
}

If the conforming type already satisfies the requirement, no implementation is needed:

extension Array: Container {}  // Array satisfies all requirements, including Element

A protocol may specify that only a class (opens new window) can implement it through using the class keyword in its inheritance list. This keyword must appear before any other inherited protocols in this list.

protocol ClassOnlyProtocol: **class**, SomeOtherProtocol {
    // Protocol requirements 
}

If a non-class type tries to implement ClassOnlyProtocol, a compiler error will be generated.

struct MyStruct: ClassOnlyProtocol { 
    // error: Non-class type 'MyStruct' cannot conform to class protocol 'ClassOnlyProtocol'  
}

Other protocols may inherit from the ClassOnlyProtocol, but they will have the same class-only requirement.

protocol MyProtocol: ClassOnlyProtocol {
    // ClassOnlyProtocol Requirements
    // MyProtocol Requirements
}

class MySecondClass: MyProtocol {
    // ClassOnlyProtocol Requirements
    // MyProtocol Requirements
}

Reference semantics of class-only protocols

Using a class-only protocol allows for reference semantics (opens new window) when the conforming type is unknown.

protocol Foo : class {
    var bar : String { get set }
}

func takesAFoo(foo:Foo) {

    // this assignment requires reference semantics,
    // as foo is a let constant in this scope.
    foo.bar = "new value"
}

In this example, as Foo is a class-only protocol, the assignment to bar is valid as the compiler knows that foo is a class type, and therefore has reference semantics.

If Foo was not a class-only protocol, a compiler error would be yielded – as the conforming type could be a value type (opens new window), which would require a var annotation in order to be mutable.

protocol Foo {
    var bar : String { get set }
}

func takesAFoo(foo:Foo) {
    foo.bar = "new value" // error: Cannot assign to property: 'foo' is a 'let' constant
}

func takesAFoo(foo:Foo) {
    **var foo = foo** // mutable copy of foo
    foo.bar = "new value" // no error – satisfies both reference and value semantics
}

Weak variables of protocol type

When applying the weak modifier (opens new window) to a variable of protocol type, that protocol type must be class-only, as weak can only be applied to reference types.

weak var weakReference : ClassOnlyProtocol?

You can write the default protocol implementation for a specific class.

protocol MyProtocol {
    func doSomething()
}

extension MyProtocol where Self: UIViewController {
    func doSomething() {
        print("UIViewController default protocol implementation")
    }
}

class MyViewController: UIViewController, MyProtocol { }

let vc = MyViewController()
vc.doSomething() // Prints "UIViewController default protocol implementation"

// RawRepresentable has an associatedType RawValue.
// For this struct, we will make the compiler infer the type
// by implementing the rawValue variable with a type of String
//
// Compiler infers RawValue = String without needing typealias
//
struct NotificationName: RawRepresentable {
    let rawValue: String

    static let dataFinished = NotificationNames(rawValue: "DataFinishedNotification")
}

This struct can be extended elsewhere to add cases

extension NotificationName {
    static let documentationLaunched = NotificationNames(rawValue: "DocumentationLaunchedNotification")
}

And an interface can design around any RawRepresentable type or specifically your enum struct

func post(notification notification: NotificationName) -> Void {
    // use notification.rawValue
}

At call site, you can use dot syntax shorthand for the typesafe NotificationName

post(notification: .dataFinished)

Using generic RawRepresentable function

// RawRepresentable has an associate type, so the 
// method that wants to accept any type conforming to
// RawRepresentable needs to be generic
func observe<T: RawRepresentable>(object: T) -> Void {
    // object.rawValue
}

Types used in Sets and Dictionaries(key) must conform to Hashable (opens new window) protocol which inherits from Equatable (opens new window) protocol.

Custom type conforming to Hashable protocol must implement

• A calculated property hashValue
• Define one of the equality operators i.e. == or !=.

Following example implements Hashable protocol for a custom struct:

struct Cell {
    var row: Int
    var col: Int
    
    init(_ row: Int, _ col: Int) {
        self.row = row
        self.col = col
    }
}

extension Cell: Hashable {
    
    // Satisfy Hashable requirement
    var hashValue: Int {
        get {
            return row.hashValue^col.hashValue
        }
    }

    // Satisfy Equatable requirement
    static func ==(lhs: Cell, rhs: Cell) -> Bool {
        return lhs.col == rhs.col && lhs.row == rhs.row
    }
    
}

// Now we can make Cell as key of dictonary
var dict = [Cell : String]()

dict[Cell(0, 0)] = "0, 0"
dict[Cell(1, 0)] = "1, 0"
dict[Cell(0, 1)] = "0, 1"

// Also we can create Set of Cells
var set = Set<Cell>()

set.insert(Cell(0, 0))
set.insert(Cell(1, 0))

Note: It is not necessary that different values in custom type have different hash values, collisions are acceptable. If hash values are equal, equality operator will be used to determine real equality.

Remarks

A Swift protocol is a collection of requirements that conforming types must implement. The protocol may then be used in most places where a type is expected, for example Arrays and generic requirements.

Protocol members always share the same access qualifier as the whole protocol, and cannot be specified separately. Although a protocol could restrict access with getter or setter requirements, as per examples above.

For more information about protocols, see The Swift Programming Language (opens new window).

Objective-C protocols (opens new window) are similar to Swift protocols.

Protocols are also comparable to Java interfaces (opens new window).