An initializer is a function called in order to bring an instance of an object type into existence. Strictly speaking, it is a static/class method, because it is called by talking to the object type. It is usually called using special syntax: the name of the type is followed directly by parentheses, as if the type itself were a function. When an initializer is called, a new instance is created and returned as a result. You will usually do something with the returned instance, such as assigning it to a variable, in order to preserve it and work with it in subsequent code.

For example, suppose we have a Dog class:

class Dog {
}

Then we can make a Dog instance like this:

Dog()

That code, however, though legal, is silly — so silly that it warrants a warning from the compiler. We have created a Dog instance, but there is no reference to that instance. Without such a reference, the Dog instance comes into existence and then immediately vanishes in a puff of smoke. The usual sort of thing is more like this:

let fido = Dog()

Now our Dog instance will persist as long as the variable fido persists (see Chapter 3) — and the variable fido gives us a reference to our Dog instance, so that we can use it.

Observe that Dog() calls an initializer even though our Dog class doesn’t declare any initializers! The reason is that object types may have implicit initializers. These are a convenience that save you the trouble of writing your own initializers. But you can write your own initializers, and you will often do so.

An initializer is a kind of function, and its declaration syntax is rather like that of a function. To declare an initializer, you use the keyword init followed by a parameter list, followed by curly braces containing the code. An object type can have multiple initializers, distinguished by their parameters. A frequent use of the parameters is to set the values of instance properties.

For example, here’s a Dog class with two instance properties, name (a String) and license (an Int). We give these instance properties default values that are effectively placeholders — an empty string and the number zero. Then we declare three initializers, so that the caller can create a Dog instance in three different ways: by supplying a name, by supplying a license number, or by supplying both. In each initializer, the parameters supplied are used to set the values of the corresponding properties:

class Dog {
    var name = ""
    var license = 0
    init(name:String) {
        self.name = name
    }
    init(license:Int) {
        self.license = license
    }
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
}

Observe that in that code, in each initializer, I’ve given each parameter the same name as the property to which it corresponds. There’s no reason to do that apart from stylistic clarity. In the code for each initializer, I can distinguish the parameter from the property by using self to access the property.

The result of that declaration is that I can create a Dog in three different ways:

let fido = Dog(name:"Fido")
let rover = Dog(license:1234)
let spot = Dog(name:"Spot", license:1357)

What I can’t do is to create a Dog with no initializer parameters. I wrote initializers, so my implicit initializer went away. This code is no longer legal:

let puff = Dog() // compile error

Of course, I could make that code legal by explicitly declaring an initializer with no parameters:

class Dog {
    var name = ""
    var license = 0
    init() {
    }
    init(name:String) {
        self.name = name
    }
    init(license:Int) {
        self.license = license
    }
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
}

Now, the truth is that we don’t need those four initializers, because an initializer is a function, and a function’s parameters can have default values. Thus, I can condense all that code into a single initializer, like this:

class Dog {
    var name = ""
    var license = 0
    init(name:String = "", license:Int = 0) {
        self.name = name
        self.license = license
    }
}

I can still make an actual Dog instance in four different ways:

let fido = Dog(name:"Fido")
let rover = Dog(license:1234)
let spot = Dog(name:"Spot", license:1357)
let puff = Dog()

Now comes the really interesting part. In my property declarations, I can eliminate the assignment of default initial values (as long as I declare explicitly the type of each property):

class Dog {
    var name : String // no default value!
    var license : Int // no default value!
    init(name:String = "", license:Int = 0) {
        self.name = name
        self.license = license
    }
}

That code is legal (and common) — because an initializer initializes! In other words, I don’t have to give my properties initial values in their declarations, provided I give them initial values in all initializers. That way, I am guaranteed that all my instance properties have values when the instance comes into existence, which is what matters. Conversely, an instance property without an initial value when the instance comes into existence is illegal. A property must be initialized either as part of its declaration or by every initializer, and the compiler will stop you otherwise.

The Swift compiler’s insistence that all instance properties be properly initialized is a valuable feature of Swift. (Contrast Objective-C, where instance properties can go uninitialized — and often do, leading to mysterious errors later.) Don’t fight the compiler; work with it. The compiler will help you by giving you an error message (“Return from initializer without initializing all stored properties”) until all your initializers initialize all your instance properties:

class Dog {
    var name : String
    var license : Int
    init(name:String = "") {
        self.name = name // compile error
    }
}

Because setting an instance property in an initializer counts as initialization, it is legal even if the instance property is a constant declared with let:

class Dog {
    let name : String
    let license : Int
    init(name:String = "", license:Int = 0) {
        self.name = name
        self.license = license
    }
}

In our artificial examples, we have been very generous with our initializer: we are letting the caller instantiate a Dog without supplying a name: argument or a license: argument. Usually, however, the purpose of an initializer is just the opposite: we want to force the caller to supply all needed information at instantiation time. Thus, in real life, it is much more likely that our Dog class would look like this:

class Dog {
    let name : String
    let license : Int
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
}

In that code, our Dog has a name property and a license property, and values for these must be supplied at instantiation time (there are no default values), and those values can never be changed thereafter (these properties are constants). In this way, we enforce a rule that every Dog must have a meaningful name and license. There is now only one way to make a Dog:

let spot = Dog(name:"Spot", license:1357)

// this property will be set automatically when the nib loads
@IBOutlet var myButton: UIButton!
// this property will be set after time-consuming gathering of data
var albums : [MPMediaItemCollection]!

struct Cat {
    var name : String
    var license : Int
    init(name:String, license:Int) {
        self.name = name
        meow() // too soon - compile error
        self.license = license
    }
    func meow() {
        print("meow")
    }
}

struct Digit {
    var number : Int
    var meaningOfLife : Bool
    init(number:Int) {
        self.number = number
        self.meaningOfLife = false
    }
    init() { // this is a delegating initializer
        self.init(number:42)
        self.meaningOfLife = true
    }
}

struct Digit { // do not do this!
    var number : Int = 100
    init(value:Int) {
        self.init(number:value)
    }
    init(number:Int) {
        self.init(value:number)
    }
}

class Dog {
    let name : String
    let license : Int
    init?(name:String, license:Int) {
        if name.isEmpty {
            return nil
        }
        if license <= 0 {
            return nil
        }
        self.name = name
        self.license = license
    }
}

A property is a variable — one that happens to be declared at the top level of an object type declaration. This means that everything said about variables in Chapter 3 applies. A property has a fixed type; it can be declared with var or let; it can be stored or computed; it can have setter observers. An instance property can also be declared lazy.

A stored instance property must be given an initial value. But, as I explained a moment ago, this doesn’t have to be through assignment in the declaration; it can be through an initializer instead. Setter observers are not called during initialization of properties.

Code that initializes a property cannot fetch an instance property or call an instance method. Such behavior would require a reference, explicit or implicit, to self; and during initialization, there is no self yet — self is exactly what we are in the process of initializing. Making this mistake can result in some of Swift’s most perplexing compile error messages. For example, this is illegal (and removing the explicit references to self doesn’t make it legal):

class Moi {
    let first = "Matt"
    let last = "Neuburg"
    let whole = self.first + " " + self.last // compile error
}

One solution in that situation would be to make whole a computed property:

class Moi {
    let first = "Matt"
    let last = "Neuburg"
    var whole : String {
        return self.first + " " + self.last
    }
}

That’s legal because the computation won’t actually be performed until after self exists. Another solution is to declare whole as lazy:

class Moi {
    let first = "Matt"
    let last = "Neuburg"
    lazy var whole : String = self.first + " " + self.last
}

Again, that’s legal because the reference to self won’t be performed until after self exists. Similarly, a property initializer can’t call an instance method, but a computed property can, and so can a lazy property.

As I demonstrated in Chapter 3, a variable’s initializer can consist of multiple lines of code if you write it as a define-and-call anonymous function. If this variable is an instance property, and if that code is to refer to other instance properties or instance methods, the variable must be declared lazy:

class Moi {
    let first = "Matt"
    let last = "Neuburg"
    lazy var whole : String = {
        var s = self.first
        s.append(" ")
        s.append(self.last)
        return s
    }()
}

If a property is an instance property (the default), it can be accessed only through an instance, and its value is separate for each instance. For example, let’s start once again with a Dog class:

class Dog {
    let name : String
    let license : Int
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
}

Our Dog class has a name instance property. Then we can make two different Dog instances with two different name values, and we can access each Dog instance’s name through the instance:

let fido = Dog(name:"Fido", license:1234)
let spot = Dog(name:"Spot", license:1357)
let aName = fido.name // "Fido"
let anotherName = spot.name // "Spot"

A static/class property, on the other hand, is accessed through the type, and is scoped to the type, which usually means that it is global and unique. I’ll use a struct as an example:

struct Greeting {
    static let friendly = "hello there"
    static let hostile = "go away"
}

Now code elsewhere can fetch the values of Greeting.friendly and Greeting.hostile. That example is neither artificial nor trivial; immutable static properties are a convenient and effective way to supply your code with nicely namespaced constants.

Unlike instance properties, static properties can be initialized with reference to one another; the reason is that static property initializers are lazy (see Chapter 3):

struct Greeting {
    static let friendly = "hello there"
    static let hostile = "go away"
    static let ambivalent = friendly + " but " + hostile
}

Notice the lack of self in that code. In static/class code, self means the type itself. I like to use self explicitly wherever it would be implicit, but here I can’t use it without arousing the ire of the compiler (I regard this as a bug). To clarify the status of the terms friendly and hostile, I can use the name of the type, just as any other code would do:

struct Greeting {
    static let friendly = "hello there"
    static let hostile = "go away"
    static let ambivalent = Greeting.friendly + " but " + Greeting.hostile
}

On the other hand, if I write ambivalent as a computed property, I can use self:

struct Greeting {
    static let friendly = "hello there"
    static let hostile = "go away"
    static var ambivalent : String {
        return self.friendly + " but " + self.hostile
    }
}

On the other other hand, I’m not allowed to use self when the initial value is set by a define-and-call anonymous function (again, I regard this as a bug):

struct Greeting {
    static let friendly = "hello there"
    static let hostile = "go away"
    static var ambivalent : String = {
        return self.friendly + " but " + self.hostile // compile error
    }()
}

A method is a function — one that happens to be declared at the top level of an object type declaration. This means that everything said about functions in Chapter 2 applies.

By default, a method is an instance method. This means that it can be accessed only through an instance. Within the body of an instance method, self is the instance. To illustrate, let’s continue to develop our Dog class:

class Dog {
    let name : String
    let license : Int
    let whatDogsSay = "Woof"
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
    func bark() {
        print(self.whatDogsSay)
    }
    func speak() {
        self.bark()
        print("I'm \(self.name)")
    }
}

Now I can make a Dog instance and tell it to speak:

let fido = Dog(name:"Fido", license:1234)
fido.speak() // Woof I'm Fido

In my Dog class, the speak method calls the instance method bark by way of self, and obtains the value of the instance property name by way of self; and the bark instance method obtains the value of the instance property whatDogsSay by way of self. This is because instance code can use self to refer to this instance. Such code can omit self if the reference is unambiguous; thus, for example, I could have written this:

func speak() {
    bark()
    print("I'm \(name)")
}

But I never write code like that (except by accident). Omitting self, in my view, makes the code harder to read and maintain; the loose terms bark and name seem mysterious and confusing. Moreover, sometimes self cannot be omitted. For example, in my implementation of init(name:license:), I must use self to disambiguate between the parameter name and the property self.name.

A static/class method is accessed through the type, and self means the type. I’ll use our Greeting struct as an example:

struct Greeting {
    static let friendly = "hello there"
    static let hostile = "go away"
    static var ambivalent : String {
        return self.friendly + " but " + self.hostile
    }
    static func beFriendly() {
        print(self.friendly)
    }
}

And here’s how to call the static beFriendly method:

Greeting.beFriendly() // hello there

There is a kind of conceptual wall between static/class members, on the one hand, and instance members on the other; even though they may be declared within the same object type declaration, they inhabit different worlds. A static/class method can’t refer to “the instance” because there is no instance; thus, a static/class method cannot directly refer to any instance properties or call any instance methods. An instance method, on the other hand, can refer to the type by name, and can thus access static/class properties and can call static/class methods.

For example, let’s return to our Dog class and grapple with the question of what dogs say. Presume that all dogs say the same thing. We’d prefer, therefore, to express whatDogsSay not at instance level but at class level. This would be a good use of a static property. Here’s a simplified Dog class that illustrates:

class Dog {
    static var whatDogsSay = "Woof"
    func bark() {
        print(Dog.whatDogsSay)
    }
}

Now we can make a Dog instance and tell it to bark:

let fido = Dog()
fido.bark() // Woof

(I’ll talk later in this chapter about another way in which an instance method can refer to the type.)

class MyClass {
    var s = ""
    func store(_ s:String) {
        self.s = s
    }
}
let m = MyClass()
let f = MyClass.store(m) // what just happened!?

f("howdy")
print(m.s) // howdy

A subscript is an instance method that is called in a special way — by appending square brackets to an instance reference. The square brackets can contain arguments to be passed to the subscript method. You can use this feature for whatever you like, but it is suitable particularly for situations where this is an object type with elements that can be appropriately accessed by key or by index number. I have already described (in Chapter 3) the use of this syntax with strings, and it is familiar also from dictionaries and arrays; you can use square brackets with strings and dictionaries and arrays exactly because Swift’s String and Dictionary and Array types declare subscript methods.

The syntax for declaring a subscript method is somewhat like a function declaration and somewhat like a computed property declaration. That’s no coincidence! A subscript is like a function in that it can take parameters: arguments can appear in the square brackets when a subscript method is called. A subscript is like a computed property in that the call is used like a reference to a property: you can fetch its value or you can assign into it.

To illustrate, I’ll write a struct that treats an integer as if it were a digit sequence, returning a digit that can be specified by an index number in square brackets; for simplicity, I’m deliberately omitting any sort of error-checking:

struct Digit {
    var number : Int
    init(_ n:Int) {
        self.number = n
    }
    subscript(ix:Int) -> Int { ❶ ❷
        get { ❸
            let s = String(self.number)
            return Int(String(s[s.index(s.startIndex, offsetBy:ix)]))!
        }
    }
}

Here’s an example of calling the getter; the instance with appended square brackets containing the arguments is used just as if you were getting a property value:

var d = Digit(1234)
let aDigit = d[1] // 2

Now I’ll expand my Digit struct so that its subscript method includes a setter (and again I’ll omit error-checking):

struct Digit {
    var number : Int
    init(_ n:Int) {
        self.number = n
    }
    subscript(ix:Int) -> Int {
        get {
            let s = String(self.number)
            return Int(String(s[s.index(s.startIndex, offsetBy:ix)]))!
        }
        set {
            var s = String(self.number)
            let i = s.index(s.startIndex, offsetBy:ix)
            s.replaceSubrange(i...i, with: String(newValue))
            self.number = Int(s)!
        }
    }
}

And here’s an example of calling the setter; the instance with appended square brackets containing the arguments is used just as if you were setting a property value:

var d = Digit(1234)
d[0] = 2 // now d.number is 2234

An object type can declare multiple subscript methods, distinguished by their parameters.

An object type may be declared inside an object type declaration, forming a nested type:

class Dog {
    struct Noise {
        static var noise = "Woof"
    }
    func bark() {
        print(Dog.Noise.noise)
    }
}

A nested object type is no different from any other object type, but the rules for referring to it from the outside are changed; the surrounding object type acts as a namespace, and must be referred to explicitly in order to access the nested object type:

Dog.Noise.noise = "Arf"

Here, the Noise struct is namespaced inside the Dog class. This namespacing provides clarity: the name Noise does not float free, but is explicitly associated with the Dog class to which it belongs. Namespacing also allows more than one Noise struct to exist, without any clash of names. Swift built-in object types often take advantage of namespacing; for example, the String struct is one of several structs that contain an Index struct, with no clash of names.

On the whole, the names of object types will be global, and you will be able to refer to them simply by using their names. Instances, however, are another story. Instances must be deliberately created, one by one. That is what instantiation is for. Once you have created an instance, you can cause that instance to persist, by storing the instance in a variable with sufficient lifetime; using that variable as a reference, you can send instance messages to that instance, accessing instance properties and calling instance methods.

Instantiation may involve you calling an initializer, or some other object may create or provide the instance for you. A simple example is what happens when you manipulate a String, like this:

let s = "Hello, world"
let s2 = s.uppercased()

In that code, we end up with two String instances. The first one, s, we created using a string literal. The second one, s2, was created for us when we called the first string’s uppercased method. Thus we have two instances, and they will persist independently as long as our references to them persist; but we didn’t get either of them by calling an initializer.

In other cases, the instance you are interested in will already exist in some persistent fashion; the problem will then be to find a way of getting a reference to that instance.

Let’s say, for example, that this is a real-life iOS app. You will certainly have a root view controller, which will be an instance of some type of UIViewController. Let’s say it’s an instance of the ViewController class. Once your app is up and running, this instance already exists. It would then be utterly counterproductive to attempt to speak to the root view controller by instantiating the ViewController class:

let theVC = ViewController() // legal but stupid

All that code does is to make a second, different instance of the ViewController class, and your messages to that instance will be wasted, as it is not the particular already existing instance that you wanted to talk to. That is a very common beginner mistake; don’t make it.

Getting a reference to an already existing instance can be, of itself, an interesting problem. The process always starts with something you already have a reference to. Often, this will be a class. In iOS programming, the app itself is an instance, and there is a class that holds a reference to that instance and will hand it to you whenever you ask for it. That class is the UIApplication class, and the way to get a reference to the app instance is through its shared class property:

let app = UIApplication.shared

Now we have a reference to the application instance. The application instance has a keyWindow property:

let window = app.keyWindow

Now we have a reference to our app’s key window. That window owns the root view controller, and will hand us a reference to it, as its own rootViewController property; the app’s keyWindow is an Optional, so to get at its rootViewController we must unwrap the Optional:

let vc = window?.rootViewController

And voilà, we have a reference to our app’s root view controller. To obtain the reference to this persistent instance, we created, in effect, a chain of method calls and properties leading from the known to the unknown, from a globally available class to the particular desired instance:

let app = UIApplication.shared
let window = app.keyWindow
let vc = window?.rootViewController

Clearly, we can write that chain as an actual chain, using repeated dot-notation:

let vc = UIApplication.shared.keyWindow?.rootViewController

You don’t have to chain your instance messages into a single line — chaining through multiple let assignments is completely efficient, possibly more legible, and certainly easier to debug — but it’s a handy formulaic convenience and is particularly characteristic of dot-notated object-oriented languages like Swift.

Optionally, when you declare an enum, you can add a type declaration. The cases then all carry with them a fixed (constant) value of that type. If the type is an integer numeric type, the values can be implicitly assigned, and will start at zero by default. For example:

enum PepBoy : Int {
    case manny
    case moe
    case jack
}

In that code, .manny carries a value of 0, .moe carries of a value of 1, and so on.

If the type is String, the implicitly assigned values are the string equivalents of the case names. For example:

enum Filter : String {
    case albums
    case playlists
    case podcasts
    case books
}

In that code, .albums carries a value of "albums", and so on.

Regardless of the type, you can assign values explicitly as part of the case declarations, like this:

enum Filter : String {
    case albums = "Albums"
    case playlists = "Playlists"
    case podcasts = "Podcasts"
    case books = "Audiobooks"
}

The types attached to an enum in this way are limited to numbers and strings, and the values assigned must be literals. The values carried by the cases are called their raw values. An instance of this enum has just one case, so it has just one fixed raw value, which can be retrieved with its rawValue property:

let type = Filter.albums
print(type.rawValue) // Albums

Having each case carry a fixed raw value can be quite useful. In my Albumen app, the Filter cases really do have those String values, and type is a view controller property; and so when the view controller wants to know what title string to put at the top of the screen, it simply retrieves self.type.rawValue.

The raw value associated with each case must be unique within this enum; the compiler will enforce this rule. Therefore, the mapping works the other way: given a raw value, you can derive the case. For example, you can instantiate an enum that has raw values by using its init(rawValue:) initializer:

let type = Filter(rawValue:"Albums")

However, the attempt to instantiate the enum in this way might fail, because you might supply a raw value corresponding to no case; therefore, this is a failable initializer, and the value returned is an Optional. In that code, type is not a Filter; it’s an Optional wrapping a Filter. This might not be terribly important, however, because the thing you are most likely to want to do with an enum is to compare it for equality with a case of the enum; you can do that with an Optional without unwrapping it. This code is legal and works correctly:

let type = Filter(rawValue:"Albums")
if type == .albums { // ...

The raw values discussed in the preceding section are fixed in advance: a given case carries with it a certain raw value, and that’s that. Alternatively, you can construct a case whose constant value can be set when the instance is created. To do so, do not declare any type for the enum as a whole; instead, append a tuple type to the name of the case. There will usually be just one type in this tuple, so what you’ll write will look like a type name in parentheses. Any type may be declared. Here’s an example:

enum Error {
    case number(Int)
    case message(String)
    case fatal
}

That code means that, at instantiation time, an Error instance with the .number case must be assigned an Int value, an Error instance with the .message case must be assigned a String value, and an Error instance with the .fatal case can’t be assigned any value. Instantiation with assignment of a value is really a way of calling an initialization function, so to supply the value, you pass it as an argument in parentheses:

let err : Error = .number(4)

The attached value here is called an associated value. What you are supplying as you specify the associated value is actually a tuple, so it can contain literal values or value references; this is legal:

let num = 4
let err : Error = .number(num)

The tuple can contain more than one value, with or without labels; if the values have labels, they must be used at initialization time:

enum Error {
    case number(Int)
    case message(String)
    case fatal(n:Int, s:String)
}
let err : Error = .fatal(n:-12, s:"Oh the horror")

An enum case that declares an associated value is actually an initialization function, so you can capture a reference to that function and call the function later:

let fatalMaker = Error.fatal
let err = fatalMaker(n:-1000, s:"Unbelievably bad error")

I’ll explain how to extract the associated value from an actual instance of such an enum in Chapter 5.

At the risk of sounding like a magician explaining his best trick, I will now reveal how an Optional works. An Optional is simply an enum with two cases: .none and .some. If it is .none, it carries no associated value, and it equates to nil. If it is .some, it carries the wrapped value as its associated value.

An explicit enum initializer must do what default initialization does: it must return a particular case of this enum. To do so, set self to the case. In this example, I’ll expand my Filter enum so that it can be initialized with a numeric argument:

enum Filter : String {
    case albums = "Albums"
    case playlists = "Playlists"
    case podcasts = "Podcasts"
    case books = "Audiobooks"
    static var cases : [Filter] = [.albums, .playlists, .podcasts, .books]
    init(_ ix:Int) {
        self = Filter.cases[ix]
    }
}

Now there are three ways to make a Filter instance:

let type1 = Filter.albums
let type2 = Filter(rawValue:"Playlists")!
let type3 = Filter(2) // .podcasts

In that example, we’ll crash in the third line if the caller passes a number that’s out of range (less than 0 or greater than 3). If we want to avoid that, we can make this a failable initializer and return nil if the number is out of range:

enum Filter : String {
    case albums = "Albums"
    case playlists = "Playlists"
    case podcasts = "Podcasts"
    case books = "Audiobooks"
    static var cases : [Filter] = [.albums, .playlists, .podcasts, .books]
    init?(_ ix:Int) {
        if !(0...3).contains(ix) {
            return nil
        }
        self = Filter.cases[ix]
    }
}

An enum can have multiple initializers. Enum initializers can delegate to one another by saying self.init(...). The only requirement is that, at some point in the calling chain, self must be set to a case; if that doesn’t happen, your enum won’t compile.

In this example, I improve my Filter enum so that it can be initialized with a String raw value without having to say rawValue: in the call. To do so, I declare a failable initializer with a string parameter that delegates to the built-in failable rawValue: initializer:

enum Filter : String {
    case albums = "Albums"
    case playlists = "Playlists"
    case podcasts = "Podcasts"
    case books = "Audiobooks"
    static var cases : [Filter] = [.albums, .playlists, .podcasts, .books]
    init?(_ ix:Int) {
        if !(0...3).contains(ix) {
            return nil
        }
        self = Filter.cases[ix]
    }
    init?(_ rawValue:String) {
        self.init(rawValue:rawValue)
    }
}

Now there are four ways to make a Filter instance:

let type1 = Filter.albums
let type2 = Filter(rawValue:"Playlists")
let type3 = Filter(2) // .Podcasts, wrapped in an Optional
let type4 = Filter("Playlists")

An enum can have instance properties and static properties, but there’s a limitation: an enum instance property can’t be a stored property. This makes sense, because if two instances of the same case could have different stored instance property values, they would no longer be equal to one another — which would undermine the nature and purpose of enums.

Computed instance properties are fine, however, and the value of the property can vary by rule in accordance with the case of self. In this example from my real code, I’ve associated an MPMediaQuery (obtained by calling an MPMediaQuery factory class method) with each case of my Filter enum, suitable for fetching the songs of that type from the music library:

enum Filter : String {
    case albums = "Albums"
    case playlists = "Playlists"
    case podcasts = "Podcasts"
    case books = "Audiobooks"
    var query : MPMediaQuery {
        switch self {
        case .albums:
            return .albums()
        case .playlists:
            return .playlists()
        case .podcasts:
            return .podcasts()
        case .books:
            return .audiobooks()
        }
    }
}

If an enum instance property is a computed variable with a setter, other code can assign to this property. However, that code’s reference to the enum instance must be a variable (var), not a constant (let). If you try to assign to an enum instance property through a let reference, you’ll get a compile error.

An enum can have instance methods (including subscripts) and static methods. Writing an enum method is straightforward. Here’s an example from my own code. In a card game, the cards draw themselves as rectangles, ellipses, or diamonds. I’ve abstracted the drawing code into an enum that draws itself as a rectangle, an ellipse, or a diamond, depending on its case:

enum Shape {
    case rectangle
    case ellipse
    case diamond
    func addShape (to p: CGMutablePath, in r : CGRect) -> () {
        switch self {
        case .rectangle:
            p.addRect(r)
        case .ellipse:
            p.addEllipse(in:r)
        case .diamond:
            p.move(to: CGPoint(x:r.minX, y:r.midY))
            p.addLine(to: CGPoint(x: r.midX, y: r.minY))
            p.addLine(to: CGPoint(x: r.maxX, y: r.midY))
                p.addLine(to: CGPoint(x: r.midX, y: r.maxY))
            p.closeSubpath()
        }
    }
}

An enum instance method that modifies the enum itself must be marked as mutating. For example, an enum instance method might assign to an instance property of self; even though this is a computed property, such assignment is illegal unless the method is marked as mutating. An enum instance method can even change the case of self, by assigning to self; but again, the method must be marked as mutating. The caller of a mutating instance method must have a variable reference to the instance (var), not a constant reference (let).

In this example, I add an advance method to my Filter enum. The idea is that the cases constitute a sequence, and the sequence can cycle. By calling advance, I transform a Filter instance into an instance of the next case in the sequence:

enum Filter : String {
    case albums = "Albums"
    case playlists = "Playlists"
    case podcasts = "Podcasts"
    case books = "Audiobooks"
    static var cases : [Filter] = [.albums, .playlists, .podcasts, .books]
    mutating func advance() {
        var ix = Filter.cases.index(of:self)!
        ix = (ix + 1) % 4
        self = Filter.cases[ix]
    }
}

And here’s how to call it:

var type = Filter.books
type.advance() // type is now Filter.albums

(A subscript setter is always considered mutating and does not have to be specially marked.)

An enum is a switch whose states have names. There are many situations where that’s a desirable thing. You could implement a multistate value yourself; for example, if there are five possible states, you could use an Int whose values can be 0 through 4. But then you would have to provide a lot of additional overhead — making sure that no other values are used, and interpreting those numeric values correctly. A list of five named cases is much better! Even when there are only two states, an enum is often better than, say, a mere Bool, because the enum’s states have names. With a Bool, you have to know what true and false signify in a particular usage; with an enum, the name of the enum and the names of its cases tell you its significance. Moreover, you can store extra information in an enum’s associated value or raw value; you can’t do that with a mere Bool.

For example, in my LinkSame app, the user can play a real game with a timer or a practice game without a timer. At various places in the code, I need to know which type of game this is. The game types are the cases of an enum:

enum InterfaceMode : Int {
    case timed = 0
    case practice = 1
}

The current game type is stored in an instance property interfaceMode, whose value is an InterfaceMode. Thus, it’s easy to set the game type by case name:

// ... initialize new game ...
self.interfaceMode = .timed

And it’s easy to examine the game type by case name:

// notify of high score only if user is not just practicing
if self.interfaceMode == .timed { // ...

So what are the raw value integers for? That’s the really clever part. They correspond to the segment indexes of a UISegmentedControl in the interface! Whenever I change the interfaceMode property, a setter observer also selects the corresponding segment of the UISegmentedControl (self.timedPractice), simply by fetching the rawValue of the current enum case:

var interfaceMode : InterfaceMode = .timed {
    willSet (mode) {
        self.timedPractice?.selectedSegmentIndex = mode.rawValue
    }
}

A struct that doesn’t have an explicit initializer and that doesn’t need an explicit initializer — because it has no stored properties, or because all its stored properties are assigned default values as part of their declaration — automatically gets an implicit initializer with no parameters, init(). For example:

struct Digit {
    var number = 42
}

That struct can be initialized by saying Digit(). But if you add any explicit initializers of your own, you lose that implicit initializer:

struct Digit {
    var number = 42
    init(number:Int) {
        self.number = number
    }
}

Now you can say Digit(number:42), but you can’t say Digit() any longer. Of course, you can add an explicit initializer that does the same thing:

struct Digit {
    var number = 42
    init() {}
    init(number:Int) {
        self.number = number
    }
}

Now you can say Digit() once again, as well as Digit(number:42).

A struct that has stored properties and that doesn’t have an explicit initializer automatically gets an implicit initializer derived from its instance properties. This is called the memberwise initializer. For example:

struct Digit {
    var number : Int // could use "let" here instead
}

That struct is legal — indeed, it is legal even if the number property is declared with let instead of var — even though it seems we have not fulfilled the contract requiring us to initialize all stored properties in their declaration or in an initializer. The reason is that this struct automatically has a memberwise initializer which does initialize all its properties. In this case, the memberwise initializer is init(number:), and you can say Digit(number:42).

The memberwise initializer exists even for var stored properties that are assigned a default value in their declaration; thus, this struct has a memberwise initializer init(number:), in addition to its implicit init() initializer:

struct Digit {
    var number = 42
}

But if you add any explicit initializers of your own, you lose the memberwise initializer (though of course you can write an explicit initializer that does the same thing).

If a struct has any explicit initializers, then they must fulfill the contract that all stored properties must be initialized either by direct initialization in the declaration or by all initializers. If a struct has multiple explicit initializers, they can delegate to one another by saying self.init(...).

A struct can have instance properties and static properties, and they can be stored or computed variables. If other code wants to set a property of a struct instance, its reference to that instance must be a variable (var), not a constant (let).

A struct can have instance methods (including subscripts) and static methods. If an instance method sets a property, it must be marked as mutating, and the caller’s reference to the struct instance must be a variable (var), not a constant (let). A mutating instance method can even replace this instance with another instance, by setting self to a different instance of the same struct. (A subscript setter is always considered mutating and does not have to be specially marked.)

I very often use a degenerate struct as a handy namespace for constants. I call such a struct “degenerate” because it consists entirely of static members; I don’t intend to use this object type to make any instances.

For example, let’s say I’m going to be storing user preference information in Cocoa’s UserDefaults. UserDefaults is a kind of dictionary: each item is accessed through a key. The keys are typically strings. A common programmer mistake is to write out these string keys literally every time a key is used; if you then misspell a key name, there’s no penalty at compile time, but your code will mysteriously fail to work correctly. The proper approach is to embody these keys as constant strings and use the names of the strings; that way, if you make a mistake typing the name of a string, the compiler can catch you. A struct with static members is a great way to define those constant strings and clump their names into a namespace:

struct Default {
    static let rows = "CardMatrixRows"
    static let columns = "CardMatrixColumns"
    static let hazyStripy = "HazyStripy"
}

That code means that I can now refer to a UserDefaults key with a name, such as Default.hazyStripy.

A major difference between enums and structs, on the one hand, and classes, on the other, is that enums and structs are value types, whereas classes are reference types.

A value type is not mutable in place, even though it seems to be. For example, consider a struct. A struct is a value type:

struct Digit {
    var number : Int
    init(_ n:Int) {
        self.number = n
    }
}

Now, Swift’s syntax of assignment would lead us to believe that changing a Digit’s number is possible:

var d = Digit(123)
d.number = 42

But in reality, when you apparently mutate an instance of a value type, you are actually replacing that instance with a different instance. To see that this is true, add a setter observer:

var d : Digit = Digit(123) {
    didSet {
        print("d was set")
    }
}
d.number = 42 // "d was set"

That explains why it is impossible to mutate a value type instance if the reference to that instance is declared with let:

struct Digit {
    var number : Int
    init(_ n:Int) {
        self.number = n
    }
}
let d = Digit(123)
d.number = 42 // compile error

Under the hood, this change would require us to replace the Digit instance pointed to by d with another Digit instance — and we can’t do that, because it would mean assigning into d, which is exactly what the let declaration forbids.

That, in turn, is why an instance method of a struct or enum that sets a property of the instance must be marked explicitly with the mutating keyword. For example:

struct Digit {
    var number : Int
    init(_ n:Int) {
        self.number = n
    }
    mutating func changeNumberTo(_ n:Int) {
        self.number = n
    }
}

Without the mutating keyword, that code won’t compile. The mutating keyword assures the compiler that you understand what’s really happening here. If that method is called, it replaces the instance; therefore, it can be called only on a reference declared with var, not let:

let d = Digit(123)
d.changeNumberTo(42) // compile error

None of what I’ve just said, however, applies to class instances! Class instances are reference types, not value types. An instance property of a class, to be settable, must be declared with var, obviously; but the reference to a class instance does not have to be declared with var in order to set that property through that reference:

class Dog {
    var name : String = "Fido"
}
let rover = Dog()
rover.name = "Rover" // fine

In the last line of that code, the class instance pointed to by rover is being mutated in place. No implicit assignment to rover is involved, and so the let declaration is powerless to prevent the mutation. A setter observer on a Dog variable is not called when a property is set:

var rover : Dog = Dog() {
    didSet {
        print("did set rover")
    }
}
rover.name = "Rover" // nothing in console

The setter observer would be called if we were to set rover explicitly (to another Dog instance), but it is not called merely because we change a property of the Dog instance already pointed to by rover.

Those examples involve a declared variable reference. Exactly the same difference between a value type and a reference type may be seen with a parameter of a function call. When we receive an instance of a value type as a parameter into a function body, the compiler will stop us in our tracks if we try to assign to its instance property. This doesn’t compile:

func digitChanger(_ d:Digit) {
    d.number = 42 // compile error
}

But this does compile:

func dogChanger(_ d:Dog) {
    d.name = "Rover"
}

With a reference type, there is in effect a concealed level of indirection between your reference to the instance and the instance itself; the reference actually refers to a pointer to the instance. This, in turn, has another important implication: it means that when a class instance is assigned to a variable or passed as an argument to a function or as the result of a function, you can wind up with multiple references to the same object. That is not true of structs and enums. When an enum instance or a struct instance is assigned or passed, what is assigned or passed is essentially a new copy of that instance. But when a class instance is assigned or passed, what is assigned or passed is a reference to the same instance.

To prove it, I’ll assign one reference to another, and then mutate the second reference — and then I’ll examine what happened to the first reference. Let’s start with the struct:

var d = Digit(123)
print(d.number) // 123
var d2 = d // assignment!
d2.number = 42
print(d.number) // 123

In that code, we changed the number property of d2, a struct instance; but nothing happened to the number property of d. Now let’s try the class:

var fido = Dog()
print(fido.name) // Fido
var rover = fido // assignment!
rover.name = "Rover"
print(fido.name) // Rover

In that code, we changed the name property of rover, a class instance — and the name property of fido was changed as well! That’s because, after the assignment in the third line, fido and rover refer to one and the same instance.

The same thing is true of parameter passing. With a class instance, what is passed is a reference to the same instance:

func dogChanger(_ d:Dog) {
    d.name = "Rover"
}
var fido = Dog()
print(fido.name) // "Fido"
dogChanger(fido)
print(fido.name) // "Rover"

The change made to d inside the function dogChanger affected our Dog instance fido! You can’t do that with an enum or struct instance parameter, because the instance is effectively copied as it is passed. But handing a class instance to a function does not copy that instance; it is more like lending that instance to the function.

The ability to generate multiple references to the same instance is significant particularly in a world of object-based programming, where objects persist and can have properties that persist along with them. If object A and object B are both long-lived objects, and if they both have a Dog property (where Dog is a class), and if they have each been handed a reference to one and the same Dog instance, then either object A or object B can mutate its Dog, and this mutation will affect the other’s Dog. You can thus be holding on to an object, only to discover that it has been mutated by someone else behind your back. If that happens unexpectedly, it can put your program into an invalid state.

Class instances are also more complicated behind the scenes. Swift has to manage their memory, precisely because there can be multiple references to the same object; this management can involve quite a bit of overhead. At an even lower level, the mere storage of class instances in memory entails some necessary overhead.

On the whole, therefore, you should prefer a value type (such as a struct) to a reference type (a class) wherever possible. Struct instances are not shared between references, and so you are relieved from any worry about such an instance being mutated behind your back; moreover, under the hood, storage and memory management are far simpler as well. New in Swift 3, the language itself will help you by imposing value types in front of many Cocoa Foundation reference types. For example, Objective-C NSDate and NSData are classes, but Swift 3 will steer you toward using struct types Date and Data instead.

But don’t get the wrong idea. Classes are not bad; they’re good! For one thing, a class instance is very efficient to pass around, because all you’re passing is a pointer. No matter how big and complicated a class instance may be, no matter how many properties it may have containing vast amounts of data, passing the instance is incredibly fast and efficient, because no new data is generated.

Even more important, there are many situations where the independent identity of a class instance, no matter how many times it is referred to, is exactly what you want. The extended lifetime of a class instance, as it is passed around, can be crucial to its functionality and integrity. In particular, only a class instance can successfully represent an independent reality. For example, a UIView needs to be a class, not a struct, because an individual UIView instance, no matter how it gets passed around, must continue to represent the same single real and persistent view in your running app’s interface.

Still another reason for preferring a class over a struct or enum is when you need recursive references. A value type cannot be structurally recursive: a stored instance property of a value type cannot be an instance of the same type. This code won’t compile:

struct Dog { // compile error
    var puppy : Dog?
}

More complex circular chains, such as a Dog with a Puppy property and a Puppy with a Dog property, are similarly illegal. But if Dog is a class instead of a struct, there’s no error. This is a consequence of the nature of memory management of value types as opposed to reference types. The moral is clear: if you need a property of a Dog to be a Dog, Dog has to be a class.

enum Node {
    case None(Int)
    indirect case left(Int, Node)
    indirect case right(Int, Node)
    indirect case both(Int, Node, Node)
}

let countedGreet = countAdder(greet)
let countedGreet2 = countAdder(greet)
countedGreet() // count is 1
countedGreet2() // count is 1

let countedGreet = countAdder(greet)
let countedGreet2 = countedGreet
countedGreet() // count is 1
countedGreet2() // count is 2

Two classes can be subclass and superclass of one another. For example, we might have a class Quadruped and a class Dog and make Quadruped the superclass of Dog. A class may have many subclasses, but a class can have only one immediate superclass. I say “immediate” because that superclass might itself have a superclass, and so on in a rising chain, until we get to the ultimate superclass, called the base class, or root class. Because a class can have many subclasses but only one superclass, there is a hierarchical tree of subclasses, each branching from its superclass, and so on, with a single class, the base class, at the top.

As far as the Swift language itself is concerned, there is no requirement that a class should have any superclass, or, if it does have a superclass, that it should ultimately be descended from any particular base class. Thus, a Swift program can have many classes that have no superclass, and it can have many independent hierarchical subclass trees, each descended from a different base class.

Cocoa, however, doesn’t work that way. In Cocoa, there is effectively just one base class — NSObject, which embodies all the functionality necessary for a class to be a class in the first place — and all other classes are subclasses, at some level, of that one base class. Cocoa thus consists of one huge tree of hierarchically arranged classes, even before you write a single line of code or create any classes of your own.

We can imagine diagramming this tree as an outline. And in fact Xcode will show you this outline (Figure 4.1): in an iOS project window, choose View → Navigators → Show Symbol Navigator and click Hierarchical, with the first and third icons in the filter bar selected (blue). The Cocoa classes are the part of the tree descending from NSObject.

Figure 4.1. Part of the Cocoa class hierarchy as shown in Xcode

The reason for having a superclass–subclass relationship in the first place is to allow related classes to share functionality. Suppose, for example, we have a Dog class and a Cat class, and we are considering declaring a walk method for both of them. We might reason that both a dog and a cat walk in pretty much the same way, by virtue of both being quadrupeds. So it might make sense to declare walk as a method of the Quadruped class, and make both Dog and Cat subclasses of Quadruped. The result is that both Dog and Cat can be sent the walk message, even if neither of them has a walk method, because each of them has a superclass that does have a walk method. We say that a subclass inherits the methods of its superclass.

To declare that a certain class is a subclass of a certain superclass, add a colon and the superclass name after the class’s name in its declaration. So, for example:

class Quadruped {
    func walk () {
        print("walk walk walk")
    }
}
class Dog : Quadruped {}
class Cat : Quadruped {}

Now let’s prove that Dog has indeed inherited walk from Quadruped:

let fido = Dog()
fido.walk() // walk walk walk

Observe that, in that code, the walk message can be sent to a Dog instance just as if the walk instance method were declared in the Dog class, even though the walk instance method is in fact declared in a superclass of Dog. That’s inheritance at work.

The purpose of subclassing is not merely so that a class can inherit another class’s methods; it’s so that it can also declare methods of its own. Typically, a subclass consists of the methods inherited from its superclass and then some. If Dog has no methods of its own, after all, it’s hard to see why it should exist separately from Quadruped. But if a Dog knows how to do something that not every Quadruped knows how to do — let’s say, bark — then it makes sense as a separate class. If we declare bark in the Dog class, and walk in the Quadruped class, and make Dog a subclass of Quadruped, then Dog inherits the ability to walk from the Quadruped class and also knows how to bark:

class Quadruped {
    func walk () {
        print("walk walk walk")
    }
}
class Dog : Quadruped {
    func bark () {
        print("woof")
    }
}

Again, let’s prove that it works:

let fido = Dog()
fido.walk() // walk walk walk
fido.bark() // woof

Within a class, it is a matter of indifference whether that class has an instance method because that method is declared in that class or because the method is declared in a superclass and inherited. A message to self works equally well either way. In this code, we have declared a barkAndWalk instance method that sends two messages to self, without regard to where the corresponding methods are declared (one is native to the subclass, one is inherited from the superclass):

class Quadruped {
    func walk () {
        print("walk walk walk")
    }
}
class Dog : Quadruped {
    func bark () {
        print("woof")
    }
    func barkAndWalk() {
        self.bark()
        self.walk()
    }
}

And here’s proof that it works:

let fido = Dog()
fido.barkAndWalk() // woof walk walk walk

It is also permitted for a subclass to redefine a method inherited from its superclass. For example, perhaps some dogs bark differently from other dogs. We might have a class NoisyDog, for instance, that is a subclass of Dog. Dog declares bark, but NoisyDog also declares bark, and defines it differently from how Dog defines it. This is called overriding. The very natural rule is that if a subclass overrides a method inherited from its superclass, then when the corresponding message is sent to an instance of that subclass, it is the subclass’s version of that method that is called.

In Swift, when you override something inherited from a superclass, you must explicitly acknowledge this fact by preceding its declaration with the keyword override. So, for example:

class Quadruped {
    func walk () {
        print("walk walk walk")
    }
}
class Dog : Quadruped {
    func bark () {
        print("woof")
    }
}
class NoisyDog : Dog {
    override func bark () {
        print("woof woof woof")
    }
}

And let’s try it:

let fido = Dog()
fido.bark() // woof
let rover = NoisyDog()
rover.bark() // woof woof woof

Observe that a subclass method by the same name as a superclass’s method is not necessarily, of itself, an override. Recall that Swift can distinguish two functions with the same name, provided they have different signatures. Those are different functions, and so an implementation of one in a subclass is not an override of the other in a superclass. An override situation exists only when the subclass redefines the same method that it inherits from a superclass — using the same name, including the external parameter names, and the same signature.

It often happens that we want to override something in a subclass and yet access the thing overridden in the superclass. This is done by sending a message to the keyword super. Our bark implementation in NoisyDog is a case in point. What NoisyDog really does when it barks is the same thing Dog does when it barks, but more times. We’d like to express that relationship in our implementation of NoisyDog’s bark. To do so, we have NoisyDog’s bark implementation send the bark message, not to self (which would be circular), but to super; this causes the search for a bark instance method implementation to start in the superclass rather than in our own class:

class Dog : Quadruped {
    func bark () {
        print("woof")
    }
}
class NoisyDog : Dog {
    override func bark () {
        for _ in 1...3 {
            super.bark()
        }
    }
}

And it works:

let fido = Dog()
fido.bark() // woof
let rover = NoisyDog()
rover.bark() // woof woof woof

A subscript function is a method. If a superclass declares a subscript, the subclass can declare a subscript with the same signature, provided it designates it with the override keyword. To call the superclass subscript implementation, the subclass can use square brackets after the keyword super (e.g. super[3]).

Along with methods, a subclass also inherits its superclass’s properties. Naturally, the subclass may also declare additional properties of its own. It is possible to override an inherited property (with some restrictions that I’ll talk about later).

A class declaration can prevent the class from being subclassed by preceding the class declaration with the final keyword. A class declaration can prevent a class member from being overridden by a subclass by preceding the member’s declaration with the final keyword.

Initialization of a class instance is considerably more complicated than initialization of a struct or enum instance, because of the existence of class inheritance. The chief task of an initializer is to ensure that all properties have an initial value, thus making the instance well-formed as it comes into existence; and an initializer may have other tasks to perform that are essential to the initial state and integrity of this instance. A class, however, may have a superclass, which may have properties and initializers of its own. Thus we must somehow ensure that when a subclass is initialized, its superclass’s properties are initialized and the tasks of its initializers are performed in good order, in addition to initializing the properties and performing the initializer tasks of the subclass itself.

Swift solves this problem coherently and reliably — and ingeniously — by enforcing some clear and well-defined rules about what a class initializer must do.

class Dog {
}
let d = Dog()

class Dog {
    var name = "Fido"
}
let d = Dog()

class Dog {
    var name = "Fido"
    init(name:String) {self.name = name}
}
let d = Dog(name:"Rover") // ok
let d2 = Dog() // compile error

class Dog {
    var name = "Fido"
    convenience init(name:String) {
        self.init()
        self.name = name
    }
}
let d = Dog(name:"Rover")
let d2 = Dog()

class Dog {
    var name : String
    var license : Int
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
}
let d = Dog(name:"Rover", license:42)

class Dog {
    var name : String
    var license : Int
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
    convenience init(license:Int) {
        self.init(name:"Fido", license:license)
    }
    convenience init() {
        self.init(license:1)
    }
}
let d = Dog()

class Dog {
    var name : String
    var license : Int
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
    convenience init(license:Int) {
        self.init(name:"Fido", license:license)
    }
}
class NoisyDog : Dog {
}

let nd1 = NoisyDog(name:"Fido", license:1)
let nd2 = NoisyDog(license:2)

let nd3 = NoisyDog() // compile error

class Dog {
    var name : String
    var license : Int
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
    convenience init(license:Int) {
        self.init(name:"Fido", license:license)
    }
}
class NoisyDog : Dog {
    convenience init(name:String) {
        self.init(name:name, license:1)
    }
}

let nd1 = NoisyDog(name:"Fido", license:1)
let nd2 = NoisyDog(license:2)
let nd3 = NoisyDog(name:"Rover")

class Dog {
    var name : String
    var license : Int
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
    convenience init(license:Int) {
        self.init(name:"Fido", license:license)
    }
}
class NoisyDog : Dog {
    init(name:String) {
        super.init(name:name, license:1)
    }
}

let nd1 = NoisyDog(name:"Rover")

class Dog {
    var name : String
    var license : Int
    init(name:String, license:Int) {
        self.name = name
        self.license = license
    }
    convenience init(license:Int) {
        self.init(name:"Fido", license:license)
    }
}
class NoisyDog : Dog {
    override init(name:String, license:Int) {
        super.init(name:name, license:license)
    }
}

let nd1 = NoisyDog(name:"Rover", license:1)
let nd2 = NoisyDog(license:2)

class Dog {
    var name : String
    required init(name:String) {
        self.name = name
    }
}
class NoisyDog : Dog {
    var obedient = false
    init(obedient:Bool) {
        self.obedient = obedient
        super.init(name:"Fido")
    }
} // compile error

class Dog {
    var name : String
    required init(name:String) {
        self.name = name
    }
}
class NoisyDog : Dog {
    var obedient = false
    init(obedient:Bool) {
        self.obedient = obedient
        super.init(name:"Fido")
    }
    required init(name:String) {
        super.init(name:name)
    }
}

A class, and only a class (not the other flavors of object type), can have a deinitializer. This is a function declared with the keyword deinit followed by curly braces containing the function body. You never call this function yourself; it is called by the runtime when an instance of this class goes out of existence. If a class has a superclass, the subclass’s deinitializer (if any) is called before the superclass’s deinitializer (if any).

The idea of a deinitializer is that you might want to perform some cleanup, or just log to the console to prove to yourself that your instance is going out of existence in good order. I’ll take advantage of deinitializers when I discuss memory management issues in Chapter 5.

A subclass can override its inherited properties. The override must have the same name and type as the inherited property, and must be marked with override. (A property cannot have the same name as an inherited property but a different type, as there is no way to distinguish them.)

The chief restriction here is that an override property cannot be a stored property. More specifically:

The overriding property’s functions may refer to — and may read from and write to — the inherited property, through the super keyword.

A class can have static members, marked static, just like a struct or an enum. It can also have class members, marked class. Both static and class members are inherited by subclasses.

The chief difference between static and class methods from the programmer’s point of view is that a static method cannot be overridden; it is as if static were a synonym for class final.

Here, for example, I’ll use a static method to express what dogs say:

class Dog {
    static func whatDogsSay() -> String {
        return "woof"
    }
    func bark() {
        print(Dog.whatDogsSay())
    }
}

A subclass now inherits whatDogsSay, but can’t override it. No subclass of Dog may contain any implementation of a class method or a static method whatDogsSay with this same signature.

Now I’ll use a class method to express what dogs say:

class Dog {
    class func whatDogsSay() -> String {
        return "woof"
    }
    func bark() {
        print(Dog.whatDogsSay())
    }
}

A subclass inherits whatDogsSay, and can override it, either as a class method or as a static method:

class NoisyDog : Dog {
    override class func whatDogsSay() -> String {
        return "WOOF"
    }
}

The difference between static properties and class properties is similar, but with an additional, rather dramatic qualification: static properties can be stored, but class properties can only be computed.

Here, I’ll use a static class property to express what dogs say:

class Dog {
    static var whatDogsSay = "woof"
    func bark() {
        print(Dog.whatDogsSay)
    }
}

A subclass inherits whatDogsSay, but can’t override it; no subclass of Dog can declare a class or static property whatDogsSay.

Now I’ll use a class property to express what dogs say. It cannot be a stored property, so I’ll have to use a computed property instead:

class Dog {
    class var whatDogsSay : String {
        return "woof"
    }
    func bark() {
        print(Dog.whatDogsSay)
    }
}

A subclass inherits whatDogsSay and can override it either as a class property or as a static property. But even as a static property the subclass’s override cannot be a stored property, in keeping with the rules of property overriding that I outlined earlier:

class NoisyDog : Dog {
    override static var whatDogsSay : String {
        return "WOOF"
    }
}

Perhaps at this point you’re scratching your head over why this is a useful thing to do. We made a Bird a Flier, but so what? If we wanted a Bird to know how to fly, why didn’t we just give Bird a fly method without adopting any protocol? The answer has to do with types. Don’t forget, a protocol is a type. Our protocol, Flier, is a type. Therefore, I can use Flier wherever I would use a type — to declare the type of a variable, for example, or the type of a function parameter:

func tellToFly(_ f:Flier) {
    f.fly()
}

Think about that code for a moment, because it embodies the entire point of protocols. A protocol is a type — so polymorphism applies. Protocols give us another way of expressing the notion of type and subtype. This means that, by the substitution principle, a Flier here could be an instance of any object type — an enum, a struct, or a class. It doesn’t matter what object type it is, as long as it adopts the Flier protocol. If it adopts the Flier protocol, it can be passed where a Flier is expected. Moreover, if it adopts the Flier protocol, then it must have a fly method, because that’s exactly what it means to adopt the Flier protocol! Therefore the compiler is willing to let us send the fly message to this object.

The converse, however, is not true: an object with a fly method is not automatically a Flier. It isn’t enough to obey the requirements of a protocol; the object type must adopt the protocol. This code won’t compile:

struct Bee {
    func fly() {
    }
}
let b = Bee()
tellToFly(b) // compile error

A Bee can be sent the fly message, qua Bee. But tellToFly doesn’t take a Bee parameter; it takes a Flier parameter. Formally, a Bee is not a Flier. To make a Bee a Flier, simply declare formally that Bee adopts the Flier protocol. This code does compile:

struct Bee : Flier {
    func fly() {
    }
}
let b = Bee()
tellToFly(b)

Enough of birds and bees; we’re ready for a real-life example! As I’ve already said, Swift is chock full of protocols already. Let’s make one of our own object types adopt one. One of the most useful Swift protocols is CustomStringConvertible. The CustomStringConvertible protocol requires that we implement a description String property. If we do that, a wonderful thing happens: when an instance of this type is used in string interpolation or print (or the po command in the console), the description property value is used automatically to represent it.

Recall, for example, the Filter enum, from earlier in this chapter. I’ll add a description property to it:

enum Filter : String {
    case albums = "Albums"
    case playlists = "Playlists"
    case podcasts = "Podcasts"
    case books = "Audiobooks"
    var description : String { return self.rawValue }
}

But that isn’t enough, in and of itself, to give Filter the power of the CustomStringConvertible protocol; to do that, we also need to adopt the CustomStringConvertible protocol formally. There is already a colon and a type in the Filter declaration, so an adopted protocol comes after a comma:

enum Filter : String, CustomStringConvertible {
    case albums = "Albums"
    case playlists = "Playlists"
    case podcasts = "Podcasts"
    case books = "Audiobooks"
    var description : String { return self.rawValue }
}

We have now made Filter formally adopt the CustomStringConvertible protocol. The CustomStringConvertible protocol requires that we implement a description String property; we do implement a description String property, so our code compiles. Now we can hand a Filter to print, or interpolate it into a string, and its description will appear automatically:

let type = Filter.albums
print(type) // Albums
print("It is \(type)") // It is Albums

Behold the power of protocols. You can give any object type the power of string conversion in exactly the same way.

Note that a type can adopt more than one protocol! For example, the built-in Double type adopts CustomStringConvertible, Hashable, Comparable, and other built-in protocols. To declare adoption of multiple protocols, list each one after the first protocol in the declaration, separated by comma. For example:

struct MyType : CustomStringConvertible, Hashable, Comparable {
    // ...
}

(Of course, that code won’t compile unless I also declare the required methods in MyType, so that MyType really does adopt those protocols.)

A protocol is a type, and an adopter of a protocol is its subtype. Polymorphism applies. Therefore, the operators for mediating between an object’s declared type and its real type work when the object is declared as a protocol type. For example, given a protocol Flier that is adopted by both Bird and Bee, we can use the is operator to test whether a particular Flier is in fact a Bird:

func isBird(_ f:Flier) -> Bool {
    return f is Bird
}

Similarly, as! and as? can be used to cast an object declared as a protocol type down to its actual type. This is important to be able to do, because the adopting object will typically be able to receive messages that the protocol can’t receive. For example, let’s say that a Bird can get a worm:

struct Bird : Flier {
    func fly() {
    }
    func getWorm() {
    }
}

A Bird can fly qua Flier, but it can getWorm only qua Bird. Thus, you can’t tell just any old Flier to get a worm:

func tellGetWorm(_ f:Flier) {
    f.getWorm() // compile error
}

But if this Flier is a Bird, clearly it can get a worm. That is exactly what casting is all about:

func tellGetWorm(f:Flier) {
    (f as? Bird)?.getWorm()
}

Protocol declaration can take place only at the top level of a file. To declare a protocol, use the keyword protocol followed by the name of the protocol, which, being an object type, should start with a capital letter. Then come curly braces which may contain the following:

A protocol can itself adopt one or more protocols; the syntax is just as you would expect — a colon after the protocol’s name in the declaration, followed by a comma-separated list of the protocols it adopts. In effect, this gives you a way to create an entire secondary hierarchy of types! The Swift headers make heavy use of this.

A protocol that adopts another protocol may repeat the contents of the adopted protocol’s curly braces, for clarity; but it doesn’t have to, as this repetition is implicit. An object type that adopts such a protocol must satisfy the requirements of this protocol and all protocols that the protocol adopts.

In Objective-C, a protocol member can be declared optional, meaning that this member doesn’t have to be implemented by the adopter, but it may be. For compatibility with Objective-C, Swift allows optional protocol members, but only in a protocol explicitly bridged to Objective-C by preceding its declaration with the @objc attribute. In such a protocol, an optional member is declared by preceding its declaration with the keywords @objc optional:

@objc protocol Flier {
    @objc optional var song : String {get}
    @objc optional func sing()
}

Only a class can adopt such a protocol, and this feature will work only if the class is an NSObject subclass, or if the optional member is marked with the @objc attribute:

class Bird : Flier {
    @objc func sing() {
        print("tweet")
    }
}

(All these @objc markings are needed because optional protocol members are not really a Swift feature; they are an Objective-C feature! Therefore, everything about an optional protocol member must be explicitly exposed to Objective-C, so that Objective-C can implement it.)

An optional member is not guaranteed to be implemented by the adopter, so Swift doesn’t know whether it’s safe to send a Flier either the song message or the sing message.

In the case of an optional property like song, Swift solves the problem by wrapping its value in an Optional. If the Flier adopter doesn’t implement the property, the result is nil and no harm done:

let f : Flier = Bird()
let s = f.song // s is an Optional wrapping a String

This is one of those rare situations where you can wind up with a double-wrapped Optional. For example, if the value of the optional property song were itself a String?, then fetching its value from a Flier would yield a String??:

@objc protocol Flier {
    @objc optional var song : String? {get}
    @objc optional func sing()
}
let f : Flier = Bird()
let s = f.song // s is an Optional wrapping an Optional wrapping a String

In the case of an optional method like sing, things are more elaborate. If the method is not implemented, we must not be permitted to call it in the first place. To handle this situation, the method itself is automatically typed as an Optional version of its declared type. To send the sing message to a Flier, therefore, you must unwrap it. The safe approach is to unwrap it optionally, with a question mark:

let f : Flier = Bird()
f.sing?()

That code compiles — and it also runs safely. The effect is to send the sing message to f only if this Flier adopter implements sing. If this Flier adopter doesn’t implement sing, nothing happens. You could have force-unwrapped the call — f.sing!() — but then your app would crash if the adopter doesn’t implement sing.

If an optional method returns a value, that value is wrapped in an Optional as well. For example:

@objc protocol Flier {
    @objc optional var song : String {get}
    @objc optional func sing() -> String
}

If we now call sing?() on a Flier, the result is an Optional wrapping a String:

let f : Flier = Bird()
let s = f.sing?() // s is an Optional wrapping a String

If we force-unwrap the call — sing!() — the result is either a String (if the adopter implements sing) or a crash (if it doesn’t).

Many Cocoa protocols have optional members. For example, your iOS app will have an app delegate class that adopts the UIApplicationDelegate protocol; this protocol has many methods, all of them optional. That fact, however, will have no effect on how you implement those methods; you don’t need to mark them in any special way. Your app delegate class is already a subclass of NSObject, so this feature just works. Either you implement a method or you don’t.

A protocol declared with the keyword class after the colon after its name is a class protocol, meaning that it can be adopted only by class object types:

protocol SecondViewControllerDelegate : class {
    func accept(data:Any!)
}

(There is no need to say class if this protocol is already marked @objc; the @objc attribute implies that this is also a class protocol.)

A typical reason for declaring a class protocol is to take advantage of special memory management features that apply only to classes. I haven’t discussed memory management yet, but I’ll continue the example anyway (and I’ll repeat it when I do talk about memory management, in Chapter 5):

class SecondViewController : UIViewController {
    weak var delegate : SecondViewControllerDelegate?
    // ...
}

The keyword weak marks the delegate property as having special memory management. Only a class instance can participate in this kind of special memory management. The delegate property is typed as a protocol, and a protocol might be adopted by a struct or an enum type. So to satisfy the compiler that this object will in fact be a class instance, and not a struct or enum instance, the protocol is declared as a class protocol.

Suppose that a protocol declares an initializer. And suppose that a class adopts this protocol. By the terms of this protocol, this class and any subclass it may ever have must implement this initializer. Therefore, the class must not only implement the initializer, but it must also mark it as required. An initializer declared in a protocol is thus implicitly required, and the class is forced to make that requirement explicit.

Consider this simple example, which won’t compile:

protocol Flier {
    init()
}
class Bird : Flier {
    init() {} // compile error
}

That code generates an elaborate but perfectly informative compile error message: “Initializer requirement init() can only be satisfied by a required initializer in non-final class Bird.” To compile our code, we must designate our initializer as required:

protocol Flier {
    init()
}
class Bird : Flier {
    required init() {}
}

The alternative, as the compile error message informs us, would be to mark the Bird class as final. This would mean that it cannot have any subclasses — thus guaranteeing that the problem will never arise in the first place. If Bird were marked final, there would be no need to mark its init as required.

In the above code, Bird is not marked as final, and its init is marked as required. This, as I’ve already explained, means in turn that any subclass of Bird that implements any designated initializers — and thus loses initializer inheritance — must implement the required initializer and mark it required as well.

That fact is responsible for a strange and annoying feature of real-life iOS programming with Swift. Let’s say you subclass the built-in Cocoa class UIViewController — something that you are extremely likely to do. And let’s say you give your subclass an initializer — something that you are also extremely likely to do:

class ViewController: UIViewController {
    init() {
        super.init(nibName: "ViewController", bundle: nil)
    }
}

That code won’t compile. The compile error says: “required initializer init(coder:) must be provided by subclass of UIViewController.”

What’s going on here? It turns out that UIViewController adopts a protocol, NSCoding. And this protocol requires an initializer init(coder:). None of that is your doing; UIViewController and NSCoding are declared by Cocoa, not by you. But that doesn’t matter! This is the same situation I was just describing. Your UIViewController subclass must either inherit init(coder:) or must explicitly implement it and mark it required. Well, your subclass has implemented a designated initializer of its own — thus cutting off initializer inheritance. Therefore it must implement init(coder:) and mark it required.

But that makes no sense if you are not expecting init(coder:) ever to be called on your UIViewController subclass. You are being forced to write an initializer for which you can provide no meaningful functionality! Fortunately, Xcode’s Fix-it feature will offer to write the initializer for you, like this:

required init?(coder aDecoder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}

That code satisfies the compiler. (I’ll explain in Chapter 5 why it’s a legal initializer even though it doesn’t fulfill an initializer’s contract.) It also deliberately crashes if it is ever called.

If you do have functionality for this initializer, you will delete the fatalError line and insert your own functionality in its place. A minimum meaningful implementation would be super.init(coder:aDecoder), but of course if your class has properties that need initialization, you will need to initialize them first.

Not only UIViewController but lots of built-in Cocoa classes adopt NSCoding. You will encounter this problem if you subclass any of those classes and implement your own initializer. It’s just something you’ll have to get used to.

One of the wonderful things about Swift is that so many of its features, rather than being built-in and accomplished by magic, are implemented in Swift and are exposed to view in the Swift header. Literals are a case in point. The reason you can say 5 to make an Int whose value is 5, instead of formally initializing Int by saying Int(5), is not because of magic (or at least, not entirely because of magic). It’s because Int adopts a protocol, ExpressibleByIntegerLiteral. Not only Int literals, but all literals work this way. The following protocols are declared in the Swift header:

Your own object type can adopt a literal convertible protocol as well. This means that a literal can appear where an instance of your object type is expected! For example, here we declare a Nest type that contains some number of eggs (its eggCount):

struct Nest : ExpressibleByIntegerLiteral {
    var eggCount : Int = 0
    init() {}
    init(integerLiteral val: Int) {
        self.eggCount = val
    }
}

Because Nest adopts ExpressibleByIntegerLiteral, we can pass an Int where a Nest is expected, and our init(integerLiteral:) will be called automatically, causing a new Nest object with the specified eggCount to come into existence at that moment:

func reportEggs(_ nest:Nest) {
    print("this nest contains \(nest.eggCount) eggs")
}
reportEggs(4) // this nest contains 4 eggs

Here’s a list of the places where generics, in one form or another, can be declared in Swift:

For generic functions and object types, which use the angle bracket syntax, the angle brackets may contain multiple placeholder names, separated by comma. For example:

func flockTwoTogether<T, U>(_ f1:T, _ f2:U) {}

The two parameters of flockTwoTogether can now be resolved to two different types (though they do not have to be different).

All our examples so far have permitted any type to be substituted for the placeholder. Alternatively, you can limit the types that are eligible to be used for resolving a particular placeholder. This is called a type constraint. The simplest form of type constraint is to put a colon and a type name after the placeholder’s name when it first appears. The type name after the colon can be a class name or a protocol name.

For example, let’s return to our Flier and its flockTogetherWith function. Suppose we want to say that the parameter of flockTogetherWith should be declared by the adopter as a type that adopts Flier. You would not do that by declaring the type of that parameter as Flier in the protocol:

protocol Flier {
    func flockTogetherWith(_ f:Flier)
}

That code says: You can’t adopt this protocol unless you declare a function flockTogetherWith whose parameter is declared as Flier:

struct Bird : Flier {
    func flockTogetherWith(_ f:Flier) {}
}

That isn’t what we want to say! We want to say that Bird should be able to adopt Flier while declaring its parameter as being of some Flier adopter type, such as Bird. The way to say that is to use a placeholder constrained as a Flier. For example, we could do it like this:

protocol Flier {
    associatedtype Other : Flier
    func flockTogetherWith(_ f:Other)
}

Unfortunately, that’s illegal: a protocol can’t use itself as a type constraint. The workaround is to declare an extra protocol that Flier itself will adopt, and constrain Other to that protocol:

protocol Superflier {}
protocol Flier : Superflier {
    associatedtype Other : Superflier
    func flockTogetherWith(_ f:Other)
}

Now Bird can be a legal adopter like this:

struct Bird : Flier {
    func flockTogetherWith(_ f:Bird) {}
}

In a generic function or a generic object type, the type constraint appears in the angle brackets. For example:

func flockTwoTogether<T:Flier>(_ f1:T, _ f2:T) {}

If Bird and Insect both adopt Flier, this flockTwoTogether function can be called with two Bird arguments or with two Insect arguments — but not with a Bird and an Insect, because T is just one placeholder, signifying one Flier adopter type. And you can’t call flockTwoTogether with two String parameters, because a String is not a Flier.

A type constraint on a placeholder is often useful as a way of assuring the compiler that some message can be sent to an instance of the placeholder type. For example, let’s say we want to implement a function myMin that returns the smallest from a list of the same type. Here’s a promising implementation as a generic function, but there’s one problem — it doesn’t compile:

func myMin<T>(_ things:T...) -> T {
    var minimum = things[0]
    for ix in 1..<things.count {
        if things[ix] < minimum { // compile error
            minimum = things[ix]
        }
    }
    return minimum
}

The problem is the comparison things[ix] < minimum. How does the compiler know that the type T, the type of things[ix] and minimum, will be resolved to a type that can in fact be compared using the less-than operator in this way? It doesn’t, and that’s exactly why it rejects that code. The solution is to promise the compiler that the resolved type of T will in fact work with the less-than operator. The way to do that, it turns out, is to constrain T to Swift’s built-in Comparable protocol; adoption of the Comparable protocol exactly guarantees that the adopter does work with the less-than operator:

func myMin<T:Comparable>(_ things:T...) -> T {

Now myMin compiles, because it cannot be called except by resolving T to an object type that adopts Comparable and hence can be compared with the less-than operator. Naturally, built-in object types that you think should be comparable, such as Int, Double, String, and Character, do in fact adopt the Comparable protocol! If you look in the Swift headers, you’ll find that the built-in min global function is declared in just this way, and for just this reason.

In the examples so far, the user of a generic resolves the placeholder’s type through inference. But there’s another way to perform resolution: the user can resolve the type manually. This is called explicit specialization. In some situations, explicit specialization is mandatory — namely, if the placeholder type cannot be resolved through inference. There are two forms of explicit specialization:

You cannot explicitly specialize a generic function. You can, however, declare a generic type with a nongeneric function that uses the generic type’s placeholder; explicit specialization of the generic type resolves the placeholder, and thus resolves the function:

protocol Flier {
    init()
}
struct Bird : Flier {
    init() {}
}
struct FlierMaker<T:Flier> {
    static func makeFlier() -> T {
        return T()
    }
}
let f = FlierMaker<Bird>.makeFlier() // returns a Bird

When a class is generic, you can subclass it, provided you resolve the generic. You can do this either through a matching generic subclass or by resolving the superclass generic explicitly. For example, here’s a generic Dog:

class Dog<T> {
    var name : T?
}

You can subclass it as a generic whose placeholder matches that of the superclass:

class NoisyDog<T> : Dog<T> {}

That’s legal because the resolution of the NoisyDog placeholder T will resolve the Dog placeholder T. The alternative is to subclass an explicitly specialized Dog:

class NoisyDog : Dog<String> {}

struct Wrapper<T> {
}
class Cat {
}
class CalicoCat : Cat {
}

let w : Wrapper<Cat> = Wrapper<CalicoCat>() // compile error

When a generic placeholder is constrained to a generic protocol with an associated type, you can refer to that type using a dot-notation chain: the placeholder name, a dot, and the associated type name.

Here’s an example. Imagine that in a game program, soldiers and archers are enemies of one another. I’ll express this by subsuming a Soldier struct and an Archer struct under a Fighter protocol that has an Enemy associated type, which is itself constrained to be a Fighter (again, I’ll need an extra protocol that Fighter adopts):

protocol Superfighter {}
protocol Fighter : Superfighter {
    associatedtype Enemy : Superfighter
}

I’ll resolve that associated type manually for both structs:

struct Soldier : Fighter {
    typealias Enemy = Archer
}
struct Archer : Fighter {
    typealias Enemy = Soldier
}

Now I’ll create a generic struct to express the opposing camps of these fighters:

struct Camp<T:Fighter> {
}

Now suppose that a camp may contain a spy from the opposing camp. What is the type of that spy? Well, if this is a Soldier camp, it’s an Archer; and if it’s an Archer camp, it’s a Soldier. More generally, since T is a Fighter, it’s the type of the Enemy of this adopter of Fighter. I can express that neatly by a chain consisting of the placeholder name T, a dot, and the associated type name Enemy:

struct Camp<T:Fighter> {
    var spy : T.Enemy?
}

The result is that if, for a particular Camp, T is resolved to Soldier, T.Enemy means Archer — and vice versa. We have created a correct and inviolable rule for the type that a Camp’s spy must be. This won’t compile:

var c = Camp<Soldier>()
c.spy = Soldier() // compile error

We’ve tried to assign an object of the wrong type to this Camp’s spy property. But this does compile:

var c = Camp<Soldier>()
c.spy = Archer()

Longer chains of associated type names are possible — in particular, when a generic protocol has an associated type which is itself constrained to a generic protocol with an associated type.

For example, let’s give each type of Fighter a characteristic weapon: a soldier has a sword, while an archer has a bow. I’ll make a Sword struct and a Bow struct, and I’ll unite them under a Wieldable protocol:

protocol Wieldable {
}
struct Sword : Wieldable {
}
struct Bow : Wieldable {
}

I’ll add a Weapon associated type to Fighter, which is constrained to be a Wieldable, and once again I’ll resolve it manually for each type of Fighter:

protocol Superfighter {
    associatedtype Weapon : Wieldable
}
protocol Fighter : Superfighter {
    associatedtype Enemy : Superfighter
}
struct Soldier : Fighter {
    typealias Weapon = Sword
    typealias Enemy = Archer
}
struct Archer : Fighter {
    typealias Weapon = Bow
    typealias Enemy = Soldier
}

Now let’s say that every Fighter has the ability to steal his enemy’s weapon. I’ll give the Fighter generic protocol a steal(weapon:from:) method. How can the Fighter generic protocol express the parameter types in a way that causes its adopter to declare this method with the proper types?

The from: parameter type is this Fighter’s Enemy. We already know how to express that: it’s the placeholder plus dot-notation with the associated type name. Here, the placeholder is the adopter of this protocol — namely, Self. So the from: parameter type is Self.Enemy. And what about the weapon: parameter type? That’s the Weapon of that Enemy! So the weapon: parameter type is Self.Enemy.Weapon:

protocol Fighter : Superfighter {
    associatedtype Enemy : Superfighter
    func steal(weapon:Self.Enemy.Weapon, from:Self.Enemy)
}

(We could omit Self from that code, and it would still compile and would mean the same thing. But Self would still be the implicit start of the chain, and I think it makes the meaning of the code clearer.)

The result is that the following declarations for Soldier and Archer correctly adopt the Fighter protocol, and the compiler approves:

struct Soldier : Fighter {
    typealias Weapon = Sword
    typealias Enemy = Archer
    func steal(weapon:Bow, from:Archer) {
    }
}
struct Archer : Fighter {
    typealias Weapon = Bow
    typealias Enemy = Soldier
    func steal (weapon:Sword, from:Soldier) {
    }
}

The example is artificial, but the concept is not. The Swift headers make heavy use of associated type chains; the associated type chain Iterator.Element is particularly common, because it expresses the type of the element of a sequence. (The Sequence generic protocol has an associated type Iterator, which is constrained to be an adopter of the generic IteratorProtocol, which in turn has an associated type Element.) Even longer associated type chains are not uncommon; for example, the LazyCollectionProtocol filter method refers to a type Self.Elements.Iterator.Element.

A simple type constraint limits the types eligible for resolving a placeholder to a single type. Sometimes, you want to limit the eligible resolving types still further: you want additional constraints.

In a generic protocol, the colon in an associated type constraint is effectively the same as the colon that appears in a type declaration. Thus, it can be followed by multiple protocols, or by a superclass and multiple protocols:

class Dog {
}
class FlyingDog : Dog, Flier {
}
protocol Flier {
}
protocol Walker {
}
protocol Generic {
    associatedtype T : Flier, Walker
    associatedtype U : Dog, Flier
}

In the Generic protocol, the associated type T can be resolved only as a type that adopts the Flier protocol and the Walker protocol, and the associated type U can be resolved only as a type that is a Dog (or a subclass of Dog) and that adopts the Flier protocol.

In the angle brackets of a generic function or object type, that syntax is illegal. In the simple case where a type is to adopt more than one protocol, you can use protocol composition:

func flyAndWalk<T: Flier & Walker> (_ f:T) {}

More generally, you can append a where clause, consisting of one or more comma-separated additional constraints on a declared placeholder:

func flyAndWalk<T> (_ f:T) where T:Flier, T:Walker {} // or T: Flier & Walker
func flyAndWalk2<T> (_ f:T) where T:Flier, T:Dog {}

A where clause can also impose additional constraints on the associated type of a generic protocol that already constrains a placeholder, using an associated type chain (described in the preceding section). This pseudocode shows what I mean; I’ve omitted the content of the where clause, to focus on what the where clause will be constraining:

protocol Flier {
    associatedtype Other
}
func flockTogether<T:Flier> (_ f:T) where T.Other /*???*/ {}

As you can see, the placeholder T is already constrained to be a Flier. Flier is itself a generic protocol, with an associated type Other. Thus, whatever type resolves T will resolve Other. The where clause is going to constrain T.Other; thus, it will constrain further the types eligible to resolve T, by restricting the types eligible to resolve Other.

So what sort of restriction are we allowed to impose on our associated type chain? One possibility is the same sort of restriction as in the preceding example — a colon followed by a protocol that it must adopt, or by a class that it must descend from. Here’s an example with a protocol:

protocol Flier {
    associatedtype Other
}
struct Bird : Flier {
    typealias Other = String
}
struct Insect : Flier {
    typealias Other = Bird
}
func flockTogether<T:Flier> (_ f:T) where T.Other:Equatable {}

Both Bird and Insect adopt Flier, but they are not both eligible as the argument in a call to the flockTogether function. The flockTogether function can be called with a Bird argument, because a Bird’s Other associated type is resolved to String, which adopts the built-in Equatable protocol. But flockTogether can’t be called with an Insect argument, because an Insect’s Other associated type is resolved to Bird, which doesn’t adopt the Equatable protocol:

flockTogether(Bird()) // okay
flockTogether(Insect()) // compile error

Instead of a colon, we can use an equality operator == followed by a type. The type at the end of the associated type chain must then be this exact type — not merely an adopter or subclass. For example:

protocol Flier {
    associatedtype Other
}
protocol Walker {
}
struct Kiwi : Walker {
}
struct Bird : Flier {
    typealias Other = Kiwi
}
struct Insect : Flier {
    typealias Other = Walker
}
func flockTogether<T:Flier> (_ f:T) where T.Other == Walker {}

The flockTogether function can be called with an Insect argument, because Insect adopts Flier and resolves Other to Walker. But it can’t be called with a Bird argument. Bird adopts Flier, and it resolves Other to an adopter of Walker, namely Kiwi — but that isn’t good enough to satisfy the == restriction.

The type on the right side of the == operator can itself be an associated type chain. The resolved types at the ends of the two chains must then be identical. For example:

protocol Flier {
    associatedtype Other
}
struct Bird : Flier {
    typealias Other = String
}
struct Insect : Flier {
    typealias Other = Int
}
func flockTwoTogether<T:Flier, U:Flier> (_ f1:T, _ f2:U)
    where T.Other == U.Other {}

The flockTwoTogether function can be called with a Bird and a Bird, and it can be called with an Insect and an Insect, but it can’t be called with an Insect and a Bird, because they don’t resolve the Other associated type to the same type.

The Swift header makes extensive use of where clauses with an == operator, especially as a way of restricting a sequence type. Take, for example, the String append(contentsOf:) method, declared like this:

mutating func append<S : Sequence>(contentsOf newElements: S)
    where S.Iterator.Element == Character

A String must consist of only Characters. The constraint means that a character sequence — but not a sequence of something else, such as Int — can be concatenated to a String:

var s = "hello"
s.append(contentsOf: " world".characters) // "hello world"

The Array append(contentsOf:) method is declared a little differently:

mutating func append<S : Sequence>(contentsOf newElements: S)
    where S.Iterator.Element == Element

An Array can consist of any type — but only one type. Array is a generic struct whose Element placeholder is the type of its elements. The constraint here enforces a rule that you can append to an Array the elements of any sort of Sequence, but only if they are the same kind of element as the elements of this array. If the array consists of String elements, you can add more String elements to it, but not Int elements.

In my real programming life, I sometimes extend a built-in Swift or Cocoa type just to encapsulate some missing functionality by expressing it as a property or method. Here are some examples from actual apps.

In a card game, I need to shuffle the deck, which is stored in an array. I extend Swift’s built-in Array type to give it a shuffle method:

extension Array {
    mutating func shuffle () {
        for i in (0..<self.count).reversed() {
            let ix1 = i
            let ix2 = Int(arc4random_uniform(UInt32(i+1)))
            (self[ix1], self[ix2]) = (self[ix2], self[ix1])
        }
    }
}

Cocoa’s Core Graphics framework has many useful functions associated with the CGRect struct, and Swift already extends CGRect to add some helpful properties and methods; but there’s no shortcut for getting the center point (a CGPoint) of a CGRect, something that in practice one very often needs. I extend CGRect to give it a center property:

extension CGRect {
    var center : CGPoint {
        return CGPoint(x:self.midX, y:self.midY)
    }
}

An extension can declare a static or class member; since an object type is usually globally available, this can be a good way to slot a global function into an appropriate namespace. For example, in one of my apps, I find myself frequently using a certain color (a UIColor). Instead of creating that color repeatedly, it makes sense to encapsulate the instructions for generating it in a global function. But instead of making that function completely global, I make it — appropriately enough — a read-only class variable of UIColor:

extension UIColor {
    class var myGolden : UIColor {
        return self.init(
            red:1.000, green:0.894, blue:0.541, alpha:0.900
        )
    }
}

Now I can use that color throughout my code as UIColor.myGolden, completely parallel to built-in class properties such as UIColor.red.

Another good use of an extension is to make built-in Cocoa classes work with your private data types. For example, in my Zotz app, I’ve defined an enum whose raw values are the key strings to be used when archiving or unarchiving a property of a Card:

enum Archive : String {
    case color = "itsColor"
    case number = "itsNumber"
    case shape = "itsShape"
    case fill = "itsFill"
}

The only problem is that in order to use this enum when archiving, I have to take its rawValue each time:

coder.encode(self.color, forKey:Archive.color.rawValue)
coder.encode(self.number, forKey:Archive.number.rawValue)
coder.encode(self.shape, forKey:Archive.shape.rawValue)
coder.encode(self.fill, forKey:Archive.fill.rawValue)

That’s just ugly. An elegant fix (suggested in a WWDC 2015 video) is to teach NSCoder, the class of coder, what to do when the forKey: argument is an Archive instead of a String. In an extension, I overload the encode(_:forKey:) method:

extension NSCoder {
    func encode(_ objv: Any?, forKey key: Archive) {
        self.encode(objv, forKey:key.rawValue)
    }
}

In effect, I’ve moved the rawValue call out of my code and into NSCoder’s code. Now I can archive a Card without saying rawValue:

coder.encode(self.color, forKey:Archive.color)
coder.encode(self.number, forKey:Archive.number)
coder.encode(self.shape, forKey:Archive.shape)
coder.encode(self.fill, forKey:Archive.fill)

Extensions on one’s own object types can help to organize one’s code. A frequently used convention is to add an extension for each protocol one’s object type needs to adopt, like this:

class ViewController: UIViewController {
    // ... UIViewController method overrides go here ...
}
extension ViewController : UIPopoverPresentationControllerDelegate {
    // ... UIPopoverPresentationControllerDelegate methods go here ...
}
extension ViewController : UIToolbarDelegate {
    // ... UIToolbarDelegate methods go here ...
}

An extension on your own object type is also a way to spread your definition of that object type over multiple files, if you feel that several shorter files are better than one long file.

When you extend a Swift struct, a curious thing happens with initializers: it becomes possible to declare an initializer and keep the implicit initializers:

struct Digit {
    var number : Int
}
extension Digit {
    init() {
        self.init(number:42)
    }
}

In that code, the explicit declaration of an initializer through an extension did not cause us to lose the implicit memberwise initializer, as would have happened if we had declared the same initializer inside the original struct declaration. Now we can instantiate a Digit by calling the explicitly declared initializer — Digit() — or by calling the implicit memberwise initializer — Digit(number:7).

When you extend a protocol, you can add methods and properties to the protocol, just as for any object type. Unlike a protocol declaration, these methods and properties are not mere requirements, to be fulfilled by the adopter of the protocol; they are actual methods and properties, to be inherited by the adopter of the protocol! For example:

protocol Flier {
}
extension Flier {
    func fly() {
        print("flap flap flap")
    }
}
struct Bird : Flier {
}

Observe that Bird can now adopt Flier without implementing the fly method. That’s because the Flier protocol extension supplies the fly method! Bird thus inherits an implementation of fly:

let b = Bird()
b.fly() // flap flap flap

An adopter can provide its own alternative implementation of a method inherited from a protocol extension:

protocol Flier {
}
extension Flier {
    func fly() {
        print("flap flap flap")
    }
}
struct Insect : Flier {
    func fly() {
        print("whirr")
    }
}
let i = Insect()
i.fly() // whirr

But be warned: this kind of inheritance is not polymorphic. The adopter’s implementation is not an override; it is merely another implementation. The internal identity rule does not apply; it matters how a reference is typed:

let f : Flier = Insect()
f.fly() // flap flap flap

Even though f is internally an Insect (as we can discover with the is operator), the fly message is being sent to an object reference typed as a Flier, so it is Flier’s implementation of the fly method that is called, not Insect’s implementation.

To get something that looks like polymorphic inheritance, we must declare fly as a requirement in the original protocol:

protocol Flier {
    func fly() // *
}
extension Flier {
    func fly() {
        print("flap flap flap")
    }
}
struct Insect : Flier {
    func fly() {
        print("whirr")
    }
}

Now an Insect maintains its internal integrity:

let f : Flier = Insect()
f.fly() // whirr

The chief benefit of protocol extensions is that they allow code to be moved to an appropriate scope. Here’s an example from my Zotz app. I have four enums, each representing an attribute of a Card: Fill, Color, Shape, and Number. They all have an Int raw value. I was tired of having to say rawValue: every time I initialized one of these enums from its raw value, so I gave each enum a delegating initializer with no externalized parameter name, that calls the built-in init(rawValue:) initializer:

enum Fill : Int {
    case empty = 1
    case solid
    case hazy
    init?(_ what:Int) {
        self.init(rawValue:what)
    }
}
enum Color : Int {
    case color1 = 1
    case color2
    case color3
    init?(_ what:Int) {
        self.init(rawValue:what)
    }
}
// ... and so on ...

However, I didn’t like the repetition of my initializer declaration. This initializer is shared by all four enums, so I’d like to write it once, as part of some type from which all four enums can inherit it. That sounds like a protocol extension! An enum with a raw value automatically adopts the built-in generic RawRepresentable protocol, where the raw value type is an associated type called RawValue. So I can shoehorn my initializer into the RawRepresentable protocol:

extension RawRepresentable {
    init?(_ what:RawValue) {
        self.init(rawValue:what)
    }
}
enum Fill : Int {
    case empty = 1
    case solid
    case hazy
}
enum Color : Int {
    case color1 = 1
    case color2
    case color3
}
// ... and so on ...

The Swift standard library makes heavy use of protocol extensions. Again, this is because protocol extensions allow code to be moved to an appropriate scope. The Swift standard library declares a lot of important protocols; protocol extensions allow those protocols to be given methods, like this:

extension Sequence {
    func enumerated() -> EnumeratedSequence<Self>
}

Without protocol extensions, the only way to apply enumeration to a Sequence, and only to a Sequence, would be to declare a global generic function with a constraint restricting the parameter to Sequence adopters. (And before Swift 2.0, when protocol extensions were introduced, that’s exactly what was declared.)

When you extend a generic type, the placeholder type names are visible to your extension declaration. That’s good, because you might need to use them; but it can make your code a little mystifying, because you seem to be using an undefined type name out of the blue. It might be a good idea to add a comment, to remind yourself what you’re up to:

class Dog<T> {
    var name : T?
}
extension Dog {
    func sayYourName() -> T? { // T is the type of self.name
        return self.name
    }
}

A generic type extension declaration can include a where clause. This has the same effect as any generic constraint: it limits which resolvers of the generic can call the code injected by this extension, and assures the compiler that your code is legal for those resolvers.

As with protocol extensions, this means that a global function can be turned into a method. Recall this example from earlier in this chapter:

func myMin<T:Comparable>(_ things:T...) -> T {
    var minimum = things[0]
    for ix in 1..<things.count {
        if things[ix] < minimum {
            minimum = things[ix]
        }
    }
    return minimum
}

That’s a global function. I’d prefer to inject it into Array as a method. Array is a generic struct whose placeholder type is called Element. To make this work, I need somehow to bring along the Comparable type constraint that makes this code legal; without it, as you remember, my use of < won’t compile. I can do that with a where clause:

extension Array where Element:Comparable {
    func myMin() -> Element {
        var minimum = self[0]
        for ix in 1..<self.count {
            if self[ix] < minimum {
                minimum = self[ix]
            }
        }
        return minimum
    }
}

The where clause is a constraint guaranteeing that this array’s elements adopt Comparable, so the compiler permits the use of the < operator — and it doesn’t permit the myMin method to be called on an array whose elements don’t adopt Comparable.

The Swift standard library makes heavy use of generic extensions. For example, in real life, there is already a min method; myMin isn’t needed. The min method is a Sequence method — and it is declared just like myMin, namely through an extension on the generic Sequence protocol with a constraint guaranteeing that the sequence’s elements are comparable:

extension Sequence where Iterator.Element : Comparable {
    func min() -> Self.Iterator.Element?
}

An interesting problem arises when you want your generic extension where clause to specify type equality (==) instead of protocol adoption or class inheritance (:). The problem is that you can’t do that with a generic struct. Suppose, for example, that I want to give Array a sum method when the elements are Ints. I can’t do it:

extension Array where Element == Int { // compile error
    func sum() -> Int {
        return self.reduce(0, +)
    }
}

But you can do it with a generic protocol, so the trick is to extend a generic protocol adopted by your struct. In this case, there is already a generic protocol adopted by Array, namely Sequence; so the solution is extend that instead:

extension Sequence where Iterator.Element == Int {
    func sum() -> Int {
        return self.reduce(0, +)
    }
}

(I’ll discuss reduce later in this chapter.)

The Any type is the universal Swift umbrella type. Where an Any object is expected, absolutely any object or function can be passed, without casting:

func anyExpecter(_ a:Any) {}
anyExpecter("howdy")     // a struct instance
anyExpecter(String.self) // a struct type
anyExpecter(Dog())       // a class instance
anyExpecter(Dog.self)    // a class type
anyExpecter(anyExpecter) // a function

Going the other way, of course, if you want to type an Any object as a more specific type, you will generally have to cast down. Such a cast is legal for any specific object type or function type. A forced cast isn’t safe, but you can easily make it safe, because you can also test an Any object against any specific object type or function type. Here, anything is typed as Any:

if anything is String {
    let s = anything as! String
    // ...
}

In Swift 3, the Any umbrella type is of great importance because it is the general medium of interchange between Swift and the Cocoa Objective-C APIs. When an Objective-C object type is nonspecific (Objective-C id), it will appear to Swift as Any. Commonly encountered examples are UserDefaults, NSCoding, and key–value coding; all of these allow you to pass an object of indeterminate class along with a string key name, and they allow you to retrieve an object of indeterminate class by a string key name. That object is typed, in Swift, as Any (or as an Optional wrapping Any, so that it can be nil).

For example:

let ud = UserDefaults.standard
let s = "howdy"
ud.set(s, forKey:"Test")

The first parameter of UserDefaults set(_:forKey:) is typed as Any. Thus, Any functions as a general conduit for crossing the bridge between the Swift world and Cocoa’s Objective-C world.

However, merely casting or assigning to Any does not in fact cross the bridge there and then. Rather, the bridge will be crossed later, when Objective-C actually receives this value and has to do something with it. At that time, it will be transformed into an object type that Objective-C can deal with. Objective-C objects must be class types. Certain common Swift types are structs, which would be meaningless to Objective-C; therefore they are automatically bridged to Objective-C class types. For example, a String becomes an NSString, and an Int becomes an NSNumber. Nonclass types that are not automatically bridged are boxed up in a way that allows them to survive the journey into Objective-C’s world, even though Objective-C can’t do anything directly with such types.

Coming back the other way, if Objective-C hands you an Any object, you will need to cast it down to its underlying type in order to do anything useful with it:

let ud = UserDefaults.standard
let test = ud.object(forKey:"Test") as! String

The result returned from UserDefaults object(forKey:) is typed as Any — actually, as an Optional wrapping an Any, because UserDefaults might need to return nil to indicate that no object exists for that key. But you know that it’s supposed to be a string, so you cast it down to String. Of course, you’d better be telling the truth when you cast down with as!, or you will crash when the code runs and the cast turns out to be impossible. You can use the as? and is operators, if you’re in doubt, to make sure your cast is safe:

let ud = UserDefaults.standard
let test = ud.object(forKey:"Test") as? String
if test != nil {
    // ...
}

AnyObject is an empty protocol (requiring no properties or methods) with the special feature that all class types conform to it automatically. Although Objective-C APIs present Objective-C id as Any in Swift, Swift AnyObject is Objective-C id. In Swift 3, AnyObject is useful primarily when you want to take advantage of the behavior of Objective-C id, as I’ll demonstrate in a moment.

A class type can be assigned directly where an AnyObject is expected; to retrieve it as its original type, you’ll need to cast down:

class Dog {
}
let d = Dog()
let anyo : AnyObject = d
let d2 = anyo as! Dog

Assigning to an AnyObject requires crossing the bridge to Objective-C then and there. If you’re not starting with a class type, you must cast (with as). If this type is automatically bridged to an Objective-C class type, it becomes that type; other types are boxed up in a way that allows them to survive the journey into Objective-C’s world, even though Objective-C can’t deal with them directly:

let s = "howdy" as AnyObject  // String to NSString to AnyObject
let i = 1 as AnyObject        // Int to NSNumber to AnyObject
let r = CGRect() as AnyObject // CGRect to boxed type to AnyObject

Thus we may imagine that when you hand a Swift object off to Objective-C as an Any value, as in the previous section, it later crosses the bridge by being cast, behind the scenes, to AnyObject.

class Dog {
    @objc var noise : String = "woof"
    @objc func bark() -> String {
        return "woof"
    }
}
class Cat {}

let c : AnyObject = Cat()
let s = c.noise

let c : AnyObject = Cat()
let s = c.bark?()

let c : AnyObject = Cat()
let s = c.bark()

func changed(_ n:Notification) {
    let player = MPMusicPlayerController.applicationMusicPlayer()
    if n.object as AnyObject? === player {
        // ...
    }
}

AnyClass is the type of AnyObject. It corresponds to the Objective-C Class type. It arises typically in declarations where a Cocoa API wants to say that a class is expected.

For example, the UIView layerClass class property is declared, in its Swift translation, like this:

class var layerClass : AnyClass {get}

That means: if you override this class property, implement your getter to return a class. This will presumably be a CALayer subclass. To return an actual class in your implementation, send the self message to the name of the class:

override class var layerClass : AnyClass {
    return CATiledLayer.self
}

A reference to an AnyClass object behaves much like a reference to an AnyObject object. You can send it any Objective-C message that Swift knows about — any Objective-C class message. To illustrate, once again I’ll start with two classes:

class Dog {
    @objc static var whatADogSays : String = "woof"
}
class Cat {}

Objective-C can see whatADogSays, and it sees it as a class property. Therefore you can send whatADogSays to an AnyClass reference:

let c : AnyClass = Cat.self
let s = c.whatADogSays

A reference to a class, such as you can obtain by applying type(of:) to an object, or by sending self to the type name, is of a type that adopts AnyClass, and you can compare references to such types with the === operator. In effect, this is a way of finding out whether two references to classes refer to the same class. This construct is valuable because you can’t use the is operator when the thing on the right side is a type reference rather than a literal type name. For example:

func typeTester(_ d:Dog, _ whattype:Dog.Type) {
    if type(of:d) === whattype {
        // ...
    }
}

The condition is true only if d is identically of type whattype. For example, if Dog has a subclass NoisyDog, then the condition is true if the parameters are Dog() and Dog.self, or if they are NoisyDog() and NoisyDog.self, but not if they are NoisyDog() and Dog.self.

An array (Array, a struct) is an ordered collection of object instances (the elements of the array) accessible by index number, where an index number is an Int numbered from 0. Thus, if an array contains four elements, the first has index 0 and the last has index 3. A Swift array cannot be sparse: if there is an element with index 3, there is also an element with index 2 and so on.

The salient feature of Swift arrays is their strict typing. Unlike some other computer languages, a Swift array’s elements must be uniform — that is, the array must consist solely of elements of the same definite type. Even an empty array must have a definite element type, despite lacking elements at this moment. An array is itself typed in accordance with its element type. Arrays whose elements are of different types are considered, themselves, to be of two different types: an array of Int elements is of a different type from an array of String elements.

If all this reminds you of Optionals, it should. Like an Optional, a Swift array is a generic. It is declared as Array<Element>, where the placeholder Element is the type of a particular array’s elements. And, like an Optional, Array types are covariant, meaning that they behave polymorphically in accordance with their element types: if NoisyDog is a subclass of Dog, then an array of NoisyDog can be used where an array of Dog is expected.

To declare or state the type of a given array’s elements, you could explicitly resolve the generic placeholder; an array of Int elements would thus be an Array<Int>. However, Swift offers syntactic sugar for stating an array’s element type, using square brackets around the name of the element type, like this: [Int]. That’s the syntax you’ll use most of the time.

A literal array is represented as square brackets containing a list of its elements separated by comma (and optional spaces): for example, [1,2,3]. The literal for an empty array is empty square brackets: [].

An array’s default initializer init(), called by appending empty parentheses to the array’s type, yields an empty array of that type. Thus, you can create an empty array of Int like this:

var arr = [Int]()

Alternatively, if a reference’s type is known in advance, the empty array [] can be inferred to that type. Thus, you can also create an empty array of Int like this:

var arr : [Int] = []

If you’re starting with a literal array containing elements, you won’t usually need to declare the array’s type, because Swift will infer it by looking at the elements. For example, Swift will infer that [1,2,3] is an array of Int. If the array element types consist of a class and its subclasses, like Dog and NoisyDog, Swift will infer the common superclass as the array’s type. However, in some cases you will need to declare an array reference’s type explicitly even while assigning a literal to that array:

let arr : [Any] = [1, "howdy"]          // mixed bag
let arr2 : [Flier] = [Insect(), Bird()] // protocol adopters

An array also has an initializer whose parameter is a sequence. This means that if a type is a sequence, you can split an instance of it into the elements of an array. For example:

Another array initializer, init(repeating:count:), lets you populate an array with the same value. In this example, I create an array of 100 Optional strings initialized to nil:

let strings : [String?] = Array(repeating:nil, count:100)

That’s the closest you can get in Swift to a sparse array; we have 100 slots, each of which might or might not contain a string (and to start with, none of them do).

let arr : [Int?] = [1,2,3]

let arr : [Int?] = [1,2,3]
print(arr) // [Optional(1), Optional(2), Optional(3)]

let dog1 : Dog = NoisyDog()
let dog2 : Dog = NoisyDog()
let arr = [dog1, dog2]
let arr2 = arr as! [NoisyDog]

let dog1 : Dog = NoisyDog()
let dog2 : Dog = NoisyDog()
let dog3 : Dog = Dog()
let arr = [dog1, dog2]
let arr2 = arr as? [NoisyDog] // Optional wrapping an array of NoisyDog
let arr3 = [dog2, dog3]
let arr4 = arr3 as? [NoisyDog] // nil

if arr is [NoisyDog] { // ...

let i1 = 1
let i2 = 2
let i3 = 3
let arr : [Int] = [1,2,3]
if arr == [i1,i2,i3] { // they are equal!

let nd1 = NoisyDog()
let d1 = nd1 as Dog
let nd2 = NoisyDog()
let d2 = nd2 as Dog
if [d1,d2] == [nd1,nd2] { // they are equal!

let arr = ["manny", "moe", "jack"]
let slice = arr[1...2]
print(slice[1]) // moe

let arr2 = Array(slice)
print(arr2[1]) // jack

var arr = [1,2,3]
arr[1] = 4 // arr is now [1,4,3]

var arr = [1,2,3]
arr[1..<2] = [7,8] // arr is now [1,7,8,3]
arr[1..<2] = [] // arr is now [1,8,3]
arr[1..<1] = [10] // arr is now [1,10,8,3] (no element was removed!)
let arr2 = [20,21]
// arr[1..<1] = arr2 // compile error! You have to say this:
arr[1..<1] = ArraySlice(arr2) // arr is now [1,20,21,10,8,3]

let arr = [[1,2,3], [4,5,6], [7,8,9]]

let arr = [[1,2,3], [4,5,6], [7,8,9]]
let i = arr[1][1] // 5

var arr = [[1,2,3], [4,5,6], [7,8,9]]
arr[1][1] = 100

let arr = [1,2,3]
let slice = arr[arr.count-2...arr.count-1] // [2,3]

let arr = [1,2,3]
let slice = arr.suffix(2) // [2,3]

let arr = [1,2,3]
let slice = arr.suffix(10) // [1,2,3] (and no crash)

let arr = [1,2,3]
let slice = arr.suffix(from:1)    // [2,3]
let slice2 = arr.prefix(upTo:1)    // [1]
let slice3 = arr.prefix(through:1) // [1,2]

let arr = [1,2,3]
let slice = arr[arr.endIndex-2..<arr.endIndex] // [2,3]

let arr = [1,2,3]
let ix = arr.index(of:2) // Optional wrapping 1

let aviary = [Bird(name:"Tweety"), Bird(name:"Flappy"), Bird(name:"Lady")]
let ix = aviary.index {$0.name.characters.count < 5} // Optional(2)

let arr = [1,2,3]
let ok = arr.contains(2) // true
let ok2 = arr.contains {$0 > 3} // false

let arr = [1,2,3]
let ok = arr.starts(with:[1,2]) // true
let ok2 = arr.starts(with:[1,-2]) {abs($0) == abs($1)} // true

let arr = [3,1,-2]
let min = arr.min() // Optional(-2)
let min2 = arr.min {abs($0)<abs($1)} // Optional(1)

var arr = [1,2,3]
arr.append(4)
arr.append(contentsOf:[5,6])
arr.append(contentsOf:7...8) // arr is now [1,2,3,4,5,6,7,8]

let arr = [1,2,3]
let arr2 = arr + [4] // arr2 is now [1,2,3,4]
var arr3 = [1,2,3]
arr3 += [4] // arr3 is now [1,2,3,4]

let arr = [[1,2], [3,4], [5,6]]
let joined = Array(arr.joined(separator:[10,11]))
// [1, 2, 10, 11, 3, 4, 10, 11, 5, 6]

let arr = [[1,2], [3,4], [5,6]]
let arr2 = Array(arr.flatten())
// [1, 2, 3, 4, 5, 6]

var arr = [4,3,5,2,6,1]
arr.sort() // [1, 2, 3, 4, 5, 6]
arr.sort {$0 > $1} // [6, 5, 4, 3, 2, 1]

var arr = [4,3,5,2,6,1]
arr.sort(by: >) // [6, 5, 4, 3, 2, 1]

let arr = [1,2,3,4,5,6]
let arr2 = arr.split {$0 % 2 == 0} // split at evens: [[1], [3], [5]]

let pepboys = ["Manny", "Moe", "Jack"]
for pepboy in pepboys {
    print(pepboy) // prints Manny, then Moe, then Jack
}

let pepboys = ["Manny", "Moe", "Jack"]
pepboys.forEach {print($0)} // prints Manny, then Moe, then Jack

let pepboys = ["Manny", "Moe", "Jack"]
for (ix,pepboy) in pepboys.enumerated() {
    print("Pep boy \(ix) is \(pepboy)") // Pep boy 0 is Manny, etc.
}
// or:
pepboys.enumerated().forEach {print("Pep boy \($0.0) is \($0.1)")}

let pepboys = ["Manny", "Moe", "Jack"]
let pepboys2 = pepboys.filter {$0.hasPrefix("M")} // [Manny, Moe]

let arr = [1,2,3]
let arr2 = arr.map {$0 * 2} // [2,4,6]

let arr = [1,2,3]
let arr2 = arr.map {Double($0)} // [1.0, 2.0, 3.0]

let path0 = IndexPath(row:0, section:sec)
let path1 = IndexPath(row:1, section:sec)
// ...

let paths = Array(0..<ct).map {IndexPath(row:$0, section:sec)}

let paths = (0..<ct).map {IndexPath(row:$0, section:sec)}

let sum = arr.reduce(/*???*/) {$0 + $1}

let arr = [1, 4, 9, 13, 112]
let sum = arr.reduce(0) {$0 + $1} // 139

let sum = arr.reduce(0, +)

let found = s.range(of:target, options:.caseInsensitive)

let arr = [["Manny", "Moe", "Jack"], ["Harpo", "Chico", "Groucho"]]
let target = "m"
let arr2 = arr.map {
    $0.filter {
        let found = $0.range(of:target, options:.caseInsensitive)
        return (found != nil)
    }
}.filter {$0.count > 0}

let arr = [UIBarButtonItem(), UIBarButtonItem()]
self.navigationItem.leftBarButtonItems = arr

let lay = CAGradientLayer()
lay.locations = [0.25, 0.5, 0.75]

let points = [oldP,p1,p2,newP] // [CGPoint]
anim.values = points

let points = [oldP,p1,p2,newP]
anim.values = points.map {NSValue(cgPoint:$0)}

let arr = ["Manny", "Moe", "Jack"]
let s = (arr as NSArray).componentsJoined(by:", ")
// s is "Manny, Moe, Jack"

var arr = ["Manny", "Moe", "Jack"]
let arr2 = NSMutableArray(array:arr)
arr2.remove("Moe")
arr = arr2 as NSArray as! [String]

let arr = UIFont.familyNames.map {
    UIFont.fontNamesForFamilyName($0)
}

@implementation Pep
- (NSArray*) boys {
    return @[@"Manny", @"Moe", @"Jack"];
}
@end

let p = Pep()
let boys = p.boys() as! [String]

A dictionary (Dictionary, a struct) is an unordered collection of object pairs. In each pair, the first object is the key; the second object is the value. The idea is that you use a key to access a value. Keys are usually strings, but they don’t have to be; the formal requirement is that they be types that are Equatable and also Hashable, meaning that they implement an Int hashValue property such that equal keys have equal hash values. Thus, the hash values can be used behind the scenes for rapid key access. Swift numeric types, strings, and enums are Hashables.

As with arrays, a given dictionary’s types must be uniform. The key type and the value type don’t have to be the same as one another, and they often will not be. But within any dictionary, all keys must be of the same type, and all values must be of the same type. Formally, a dictionary is a generic, and its placeholder types are ordered key type, then value type: Dictionary<Key,Value>. As with arrays, however, Swift provides syntactic sugar for expressing a dictionary’s type, which is what you’ll usually use: [Key: Value]. That’s square brackets containing a colon (and optional spaces) separating the key type from the value type. This code creates an empty dictionary whose keys (when they exist) will be Strings and whose values (when they exist) will be Strings:

var d = [String:String]()

The colon is used also between each key and value in the literal syntax for expressing a dictionary. The key–value pairs appear between square brackets, separated by comma, just like an array. This code creates a dictionary by describing it literally (and the dictionary’s type of [String:String] is inferred):

var d = ["CA": "California", "NY": "New York"]

The literal for an empty dictionary is square brackets containing just a colon: [:]. This notation can be used provided the dictionary’s type is known in some other way. Thus, this is another way to create an empty [String:String] dictionary:

var d : [String:String] = [:]

If you try to fetch a value through a nonexistent key, there is no error, but Swift needs a way to report failure; therefore, it returns nil. This, in turn, implies that the value returned when you successfully access a value through a key must be an Optional wrapping the real value!

Access to a dictionary’s contents is usually by subscripting. To fetch a value by key, subscript the key to the dictionary reference:

let d = ["CA": "California", "NY": "New York"]
let state = d["CA"]

Bear in mind, however, that after that code, state is not a String — it’s an Optional wrapping a String! Forgetting this is a common beginner mistake.

If the reference to a dictionary is mutable, you can also assign into a key subscript expression. If the key already exists, its value is replaced. If the key doesn’t already exist, it is created and the value is attached to it:

var d = ["CA": "California", "NY": "New York"]
d["CA"] = "Casablanca"
d["MD"] = "Maryland"
// d is now ["MD": "Maryland", "NY": "New York", "CA": "Casablanca"]

Alternatively, call updateValue(forKey:); it has the advantage that it returns the old value wrapped in an Optional, or nil if the key wasn’t already present.

By a kind of shorthand, assigning nil into a key subscript expression removes that key–value pair if it exists:

var d = ["CA": "California", "NY": "New York"]
d["NY"] = nil // d is now ["CA": "California"]

Alternatively, call removeValue(forKey:); it has the advantage that it returns the removed value before it removes the key–value pair. The removed value is returned wrapped in an Optional, so a nil result tells you that this key was never in the dictionary to begin with.

As with arrays, a dictionary type is legal for casting down, meaning that the individual elements will be cast down. Typically, only the value types will differ:

let dog1 : Dog = NoisyDog()
let dog2 : Dog = NoisyDog()
let d = ["fido": dog1, "rover": dog2]
let d2 = d as! [String : NoisyDog]

As with arrays, is can be used to test the actual types in the dictionary, and as? can be used to test and cast safely. Dictionary equality, like array equality, works as you would expect.

var d = ["CA": "California", "NY": "New York"]
for s in d.keys {
    print(s) // s is a String
}

var d = ["CA": "California", "NY": "New York"]
var keys = Array(d.keys)

var d = ["CA": "California", "NY": "New York"]
for (abbrev, state) in d {
    print("\(abbrev) stands for \(state)")
}

var d = ["CA": "California", "NY": "New York"]
let arr = Array(d) // [("NY", "New York"), ("CA", "California")]

let sum = d.values.reduce(0, +)

let min = d.values.min()

let arr = Array(d.values.filter{$0 < 2})

let keysSorted = d.keys.sorted()

let prog = (n.userInfo?["progress"] as? NSNumber)?.doubleValue
if prog != nil {
    self.progress = prog!
}

UINavigationBar.appearance().titleTextAttributes = [
    NSFontAttributeName : UIFont(name: "ChalkboardSE-Bold", size: 20)!,
    NSForegroundColorAttributeName : UIColor.darkText,
    NSShadowAttributeName : {
        let shad = NSShadow()
        shad.shadowOffset = CGSize(width:1.5,height:1.5)
        return shad
    }()
]

var d1 = ["NY":"New York", "CA":"California"]
let d2 = ["MD":"Maryland"]
let mutd1 = NSMutableDictionary(dictionary:d1)
mutd1.addEntries(from:d2)
d1 = mutd1 as NSDictionary as! [String:String]
// d1 is now ["MD": "Maryland", "NY": "New York", "CA": "California"]

extension Dictionary {
    mutating func addEntries(from d:[Key:Value]) {
        for (k,v) in d {
            self[k] = v
        }
    }
}

A set (Set, a struct) is an unordered collection of unique objects. Its elements must be all of one type; it has a count and an isEmpty property; it can be initialized from any sequence; you can cycle through its elements with for...in. But the order of elements is not guaranteed, and you should make no assumptions about it.

The uniqueness of set elements is implemented by constraining their type to be Equatable and Hashable, just like the keys of a Dictionary. Thus, the hash values can be used behind the scenes for rapid access. Checking whether a set contains a given element, which you can do with the contains(_:) instance method, is very efficient — far more efficient than doing the same thing with an array. Therefore, if element uniqueness is acceptable (or desirable) and you don’t need indexing or a guaranteed order, a set can be a much better choice of collection than an array.

The fact that a set’s elements are Hashables means that they must also be Equatables. This makes sense, because the notion of uniqueness depends upon being able to answer the question of whether a given object is already in the set.

There are no set literals in Swift, but you won’t need them because you can pass an array literal where a set is expected. There is no syntactic sugar for expressing a set type, but the Set struct is a generic, so you can express the type by explicitly specializing the generic:

let set : Set<Int> = [1, 2, 3, 4, 5]

In that particular example, however, there was no need to specialize the generic, as the Int type can be inferred from the array.

It sometimes happens (more often than you might suppose) that you want to examine one element of a set as a kind of sample. Order is meaningless, so it’s sufficient to obtain any element, such as the first element. For this purpose, use the first instance property; it returns an Optional, just in case the set is empty.

The distinctive feature of a set is the uniqueness of its objects. If an object is added to a set and that object is already present, it isn’t added a second time. Conversion from an array to a set and back to an array is thus a quick and reliable way of uniquing the array — though of course order is not preserved:

let arr = [1,2,1,3,2,4,3,5]
let set = Set(arr)
let arr2 = Array(set) // [5, 2, 3, 1, 4], perhaps

A set is a Collection and a Sequence, so it is analogous to an array or a dictionary, and what I have already said about those types generally applies to a set as well. For example, Set has a map(_:) instance method; it returns an array, but of course you can turn that right back into a set if you need to:

let set : Set = [1,2,3,4,5]
let set2 = Set(set.map {$0+1}) // {6, 5, 2, 3, 4}, perhaps

If the reference to a set is mutable, a number of instance methods spring to life. You can add an object with insert(_:); there is no penalty for trying to add an object that’s already in the set. (To learn what happened, capture and examine the result of the insert call.) You can remove an object and return it by specifying the object itself, or something equatable to it, with the remove(_:) method; it returns the object wrapped in an Optional, or nil if the object was not present. You can remove and return the first object, whatever “first” may mean, with removeFirst; it crashes if the set is empty, so take precautions — or use popFirst, which is safe.

Equality comparison (==) is defined for sets as you would expect; two sets are equal if every element of each is also an element of the other.

If the notion of a set brings to your mind visions of Venn diagrams from elementary school, that’s good, because sets have instance methods giving you all those set operations you remember so fondly. The parameter can be a set, or it can be any sequence, which will be converted to a set; for example, it might be an array, a range, or even a character sequence:

Here’s a real-life example of elegant Set usage from one of my apps. I have a lot of numbered pictures, of which we are to choose one randomly. But I don’t want to choose a picture that has recently been chosen. Therefore, I keep a list of the numbers of all recently chosen pictures. When it’s time to choose a new picture, I convert the list of all possible numbers to a Set, convert the list of recently chosen picture numbers to a Set, and subtract(_:) to get a list of unused picture numbers! Now I choose a picture number at random and add it to the list of recently chosen picture numbers:

let ud = UserDefaults.standard
var recents = ud.object(forKey:Defaults.recents) as? [Int]
if recents == nil {
    recents = []
}
var forbiddenNumbers = Set(recents!)
let legalNumbers = Set(1...PIXCOUNT).subtracting(forbiddenNumbers)
let newNumber = Array(legalNumbers)[
    Int(arc4random_uniform(UInt32(legalNumbers.count)))
]
forbiddenNumbers.insert(newNumber)
ud.set(Array(forbiddenNumbers), forKey:Defaults.recents)

typedef NS_OPTIONS(NSUInteger, UIViewAnimationOptions) {
    UIViewAnimationOptionLayoutSubviews            = 1 << 0,
    UIViewAnimationOptionAllowUserInteraction      = 1 << 1,
    UIViewAnimationOptionBeginFromCurrentState     = 1 << 2,
    UIViewAnimationOptionRepeat                    = 1 << 3,
    UIViewAnimationOptionAutoreverse               = 1 << 4,
    // ...
};

UIViewAnimationOptions.layoutSubviews          0b00000001
UIViewAnimationOptions.allowUserInteraction    0b00000010
UIViewAnimationOptions.beginFromCurrentState   0b00000100
UIViewAnimationOptions.repeat                  0b00001000
UIViewAnimationOptions.autoreverse             0b00010000

let val =
    UIViewAnimationOptions.autoreverse.rawValue |
    UIViewAnimationOptions.repeat.rawValue
let opts = UIViewAnimationOptions(rawValue: val)

var opts = UIViewAnimationOptions.autoreverse
opts.insert(.repeat)

let opts : UIViewAnimationOptions = [.autoreverse, .repeat]

override func didTransition(to state: UITableViewCellStateMask) {
    let editing = UITableViewCellStateMask.showingEditControlMask.rawValue
    if state.rawValue & editing != 0 {
        // ... the ShowingEditControlMask bit is set ...
    }
}

override func didTransition(to state: UITableViewCellStateMask) {
    if state.contains(.showingEditControlMask) {
        // ... the ShowingEditControlMask bit is set ...
    }
}

override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
    let t = touches.first // an Optional wrapping a UITouch
    // ...
}