Protocol extensions and generics

Default implementations

protocol Greeter {
    var name: String { get }
    func greet() -> String
}

extension Greeter {
    func greet() -> String {
        "Hello, \(name)!"
    }
}

struct Person: Greeter {
    var name: String
}

Person never implements greet() and gets it anyway. A conforming type can override the default by providing its own.

Notice shout() — defined only in the extension, in terms of greet(). Each type gets it without writing anything, and it correctly picks up the overridden greet for the pirate.

Constrained extensions

An extension can apply only where a condition holds:

extension Collection where Element: Numeric {
    var total: Element {
        reduce(0, +)
    }
}

[1, 2, 3].total          // 6
["a", "b"].total         // error: no such member

This is how the standard library gives [Int] a sum-like capability without polluting [String]. Constrained extensions are one of Swift's sharpest tools: behaviour appears exactly where it makes sense and nowhere else.

Generics: one implementation, many types

A generic function keeps the caller's concrete type instead of erasing it:

func firstOrNil<T>(_ items: [T]) -> T? {
    items.isEmpty ? nil : items[0]
}

firstOrNil([1, 2, 3])       // Int?
firstOrNil(["a"])           // String?

T is a placeholder filled in at each call site. Two things are guaranteed: the concrete type is preserved, and there is no existential box. On top of that, when the optimiser can see the function's body (same module with optimisation on, or @inlinable), it generates specialised code per concrete type and can inline the calls — without that visibility, generic code still routes protocol requirements through a small runtime lookup table. Specialisation is an optimisation you usually get, not a language guarantee.

Constraints

An unconstrained T can do almost nothing — the compiler knows nothing about it. Constraints add capability:

func largest<T: Comparable>(_ items: [T]) -> T? {
    items.max()
}

func describe<T: CustomStringConvertible>(_ value: T) -> String {
    "value: \(value.description)"
}

where clauses handle more elaborate conditions:

func merge<C: Collection>(_ collection: C) -> String where C.Element == String {
    collection.joined(separator: ", ")
}

Generic types

struct Stack<Element> {
    private var items: [Element] = []

    mutating func push(_ item: Element) {
        items.append(item)
    }

    mutating func pop() -> Element? {
        items.popLast()
    }

    var count: Int { items.count }
    var isEmpty: Bool { items.isEmpty }
}

var numbers = Stack<Int>()
var words = Stack<String>()

Array, Dictionary, Set and Optional are all generic types written exactly this way.

Generic or existential?

Both let one function work with several types. They are not interchangeable.

Associated types

A protocol can have a placeholder type of its own:

protocol Container {
    associatedtype Item
    var count: Int { get }
    mutating func append(_ item: Item)
    subscript(index: Int) -> Item { get }
}

struct IntStack: Container {
    var items: [Int] = []
    var count: Int { items.count }
    mutating func append(_ item: Int) { items.append(item) }
    subscript(index: Int) -> Int { items[index] }
}

Item is inferred from the implementation — here, Int. This is how Collection declares Element and Iterator.

Associated types are also why some protocols cannot be used as plain existentials without care: any Container does not say what it contains. Swift 5.7 made this workable with primary associated types (any Container<Int>), but generics remain the cleaner answer.