The Swift branching construct with if is similar to C. Many examples of if constructs have appeared already in this book. The construct may be formally summarized as shown in Example 5.1.

if condition {
    statements
}

if condition {
    statements
} else {
    statements
}

if condition {
    statements
} else if condition {
    statements
} else {
    statements
}

The third form, containing else if, can have as many else if blocks as needed, and the final else block may be omitted.

Here’s a real-life if construct that lies at the heart of one of my apps:

// okay, we've tapped a tile; there are three cases
if self.selectedTile == nil { // no selected tile: select and play this tile
    self.select(tile:tile)
    self.play(tile:tile)
} else if self.selectedTile == tile { // selected tile tapped: deselect it
    self.deselectAll()
    self.player?.pause()
} else { // there was a selected tile, another tile was tapped: swap them
    self.swap(self.selectedTile, with:tile, check:true, fence:true)
}

In Swift, if can be followed immediately by a variable declaration and assignment — that is, by let or var and a new local variable name, possibly followed by a colon and a type declaration, then an equal sign and a value. This syntax, called a conditional binding, is actually a shorthand for conditionally unwrapping an Optional. The assigned value is expected to be an Optional — the compiler will stop you if it isn’t — and this is what happens:

Thus, a conditional binding is a convenient shorthand for safely passing an unwrapped Optional into a block. The Optional is unwrapped, and the block is executed, only if the Optional can be unwrapped.

It is perfectly reasonable for the local variable in a conditional binding to have the same name as an existing variable in the surrounding scope. It can even have the same name as the Optional being unwrapped! There is then no need to make up a new name, and inside the block the unwrapped value of the Optional overshadows the original Optional, which thus cannot be accessed accidentally.

Here’s an example of a conditional binding. Recall this code from Chapter 4, where I optionally unwrap a Notification’s userInfo dictionary, attempt to fetch a value from the dictionary using the "progress" key, and proceed only if that value turns out to be an NSNumber:

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

We can rewrite that code as a conditional binding:

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

It is also possible to nest conditional bindings. To illustrate, I’ll rewrite the previous example to use a separate conditional binding for every Optional in the chain:

if let ui = n.userInfo {
    if let prog = ui["progress"] as? NSNumber {
        self.progress = prog.doubleValue
    }
}

The result, if the chain involves many optional unwrappings, can be somewhat verbose and the nest can become deeply indented — Swift programmers like to call this the “pyramid of doom” — but in my view it is also considerably more legible, because the structure reflects perfectly the successive stages of testing. To help avoid the indentation, successive conditional bindings can be combined into a condition list, with each condition separated by comma:

if let ui = n.userInfo, let prog = ui["progress"] as? NSNumber {
    self.progress = prog.doubleValue
}

In that code, the assignment to prog won’t even be attempted if the assignment to ui fails (because n.userInfo is nil).

Condition lists do not have to consist solely of conditional bindings. They can include ordinary conditions. The important thing is the left-to-right order of evaluation, which allows each condition to depend upon the previous one. Here’s a real-life example from my own code. The “pyramid of doom” consists of four nested conditions:

override func observeValue(forKeyPath keyPath: String?,
    of object: Any?, change: [NSKeyValueChangeKey : Any]?,
    context: UnsafeMutableRawPointer?) {
        if keyPath == readyForDisplay {
            if let obj = object as? AVPlayerViewController {
                if let ok = change?[.newKey] as? Bool {
                    if ok {
                        // ...
                    }
                }
            }
        }
}

Alternatively, those four conditions can be combined into a single list:

override func observeValue(forKeyPath keyPath: String?,
    of object: Any?, change: [NSKeyValueChangeKey : Any]?,
    context: UnsafeMutableRawPointer?) {
        if keyPath == readyForDisplay,
        let obj = object as? AVPlayerViewController,
        let ok = change?[.newKey] as? Bool,
        ok {
            // ...
        }
}

But whether the second version is more legible is an open question.

Alternatively, you can express the chain of conditions as a series of guard statements (see Guard); I think I like this idiom best:

override func observeValue(forKeyPath keyPath: String?,
    of object: Any?, change: [NSKeyValueChangeKey : Any]?,
    context: UnsafeMutableRawPointer?) {
        guard keyPath == readyForDisplay else {return}
        guard let obj = object as? AVPlayerViewController else {return}
        guard let ok = change?[.newKey] as? Bool else {return}
        guard ok else {return}
        // ...
}

A switch statement is a neater way of writing an extended if...else if...else construct. In C (and Objective-C), a switch statement contains hidden traps; Swift eliminates those traps, and adds power and flexibility. As a result, switch statements are commonly used in Swift (whereas they are relatively rare in my Objective-C code).

In a switch statement, the condition involves the comparison of different possible values, called cases, against a single value, called the tag. The case comparisons are performed successively in order. As soon as a case comparison succeeds, that case’s code is executed and the entire switch statement is exited. The schema is shown in Example 5.2; there can be as many cases as needed, and the default case can be omitted (subject to restrictions that I’ll explain in a moment).

switch tag {
case pattern1:
    statements
case pattern2:
    statements
default:
    statements
}

Here’s an actual example:

switch i {
case 1:
    print("You have 1 thingy!")
case 2:
    print("You have 2 thingies!")
default:
    print("You have \(i) thingies!")
}

In that code, a variable i functions as the tag. The value of i is first compared to the value 1. If it is 1, that case’s code is executed and that’s all. If it is not 1, it is compared to the value 2. If it is 2, that case’s code is executed and that’s all. If the value of i matches neither of those, the default case’s code is executed.

In Swift, a switch statement must be exhaustive. This means that every possible value of the tag must be covered by a case. The compiler will stop you if you try to violate this rule. The rule makes intuitive sense when a value’s type allows only a limited number of possibilities; the usual example is an enum, which itself has a small, fixed set of cases as its possible values. But when, as in the preceding example, the tag is an Int, there is an infinite number of possible individual cases. Thus, a “mop-up” case must appear, to mop up all the cases that you didn’t write explicitly. A common way to write a “mop-up” case is to use a default case.

Each case’s code can consist of multiple lines; it doesn’t have to be a single line, as the cases in the preceding example happen to be. However, it must consist of at least a single line; it is illegal for a Swift switch case to be completely empty. It is legal for the first (or only) line of a case’s code to appear on the same line as the case, after the colon; thus, I could have written the preceding example like this:

switch i {
case 1: print("You have 1 thingy!")
case 2: print("You have 2 thingies!")
default: print("You have \(i) thingies!")
}

The minimum single line of case code is the keyword break; used in this way, break acts as a placeholder meaning, “Do nothing.” It is very common for a switch statement to include a default (or other “mop-up” case) consisting of nothing but the keyword break; in this way, you exhaust all possible values of the tag, but if the value is one that no case explicitly covers, you do nothing.

Now let’s focus on the comparison between the tag value and the case value. In the preceding example, it works like an equality comparison (==); but that isn’t the only possibility. In Swift, a case value is actually a special expression called a pattern, and the pattern is compared to the tag value using a “secret” pattern-matching operator, ~=. The more you know about the syntax for constructing a pattern, the more powerful your case values and your switch statements will be.

A pattern can include an underscore (_) to absorb all values without using them. An underscore case is thus an alternative form of “mop-up” case:

switch i {
case 1:
    print("You have 1 thingy!")
case _:
    print("You have many thingies!")
}

A pattern can include a declaration of a local variable name (an unconditional binding) to absorb all values and use the actual value. This is another alternative form of “mop-up” case:

switch i {
case 1:
    print("You have 1 thingy!")
case let n:
    print("You have \(n) thingies!")
}

When the tag is a Comparable, a case can include a Range; the test involves sending the Range the contains message:

switch i {
case 1:
    print("You have 1 thingy!")
case 2...10:
    print("You have \(i) thingies!")
default:
    print("You have more thingies than I can count!")
}

When the tag is an Optional, a case can test it against nil. Thus, a possible way to unwrap an Optional safely is to test against nil first and then unwrap in a subsequent case, since we’ll never reach the unwrapping if the nil test succeeds. In this example, i is an Optional wrapping an Int:

switch i {
case nil: break
default:
    switch i! {
    case 1:
        print("You have 1 thingy!")
    case let n:
        print("You have \(n) thingies!")
    }
}

That seems a bit clumsy, however, so there’s a special syntax: appending ? to a case pattern safely unwraps an Optional tag. Thus, we can rewrite that example like this:

switch i {
case 1?:
    print("You have 1 thingy!")
case let n?:
    print("You have \(n) thingies!")
case nil: break
}

When the tag is a Bool, a case can test it against a condition. Thus, by a clever perversion, you can use the cases to test any conditions you like — by using true as the tag! A switch statement thus becomes a genuine substitute for an extended if...else if construct. In this example from my own code, I could have used if...else if, but each case is just one line, so a switch statement seems clearer:

func position(for bar: UIBarPositioning) -> UIBarPosition {
    switch true {
    case bar === self.navbar:  return .topAttached
    case bar === self.toolbar: return .bottom
    default:                   return .any
    }
}

A pattern can include a where clause adding a condition to limit the truth value of the case. This is often, though not necessarily, used in combination with a binding; the condition can refer to the variable declared in the binding:

switch i {
case let j where j < 0:
    print("i is negative")
case let j where j > 0:
    print("i is positive")
case 0:
    print("i is 0")
default:break
}

A pattern can include the is operator to test the tag’s type. In this example, assume that we have a Dog class and its NoisyDog subclass, and that d is typed as Dog:

switch d {
case is NoisyDog:
    print("You have a noisy dog!")
case _:
    print("You have a dog.")
}

A pattern can include a cast with the as (not as?) operator. Typically, you’ll combine this with a binding that declares a local variable; despite the use of unconditional as, the value is conditionally cast and, if the cast succeeds, the local variable carries the cast value into the case code. Again, d is typed as Dog; assume that Dog implements bark and that NoisyDog implements beQuiet:

switch d {
case let nd as NoisyDog:
    nd.beQuiet()
case let d:
    d.bark()
}

You can also use as (not as?) to cast down the tag (and possibly unwrap it) conditionally as part of a test against a specific match; in this example, i might be an Any or an Optional wrapping an Any:

switch i {
case 0 as Int:
    print("It is 0")
default:break
}

You can perform multiple tests at once by expressing the tag as a tuple and wrapping the corresponding tests in a tuple. The case passes only if every test in the test tuple succeeds against the corresponding member of the tag tuple. In this example, we start with a dictionary d typed as [String:Any]. Using a tuple, we can safely attempt to extract and cast two values at once:

switch (d["size"], d["desc"]) {
case let (size as Int, desc as String):
    print("You have size \(size) and it is \(desc)")
default:break
}

When a tag is an enum, the cases can be cases of the enum. A switch statement is thus an excellent way to handle an enum. Here’s the Filter enum:

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

And here’s a switch statement, where the tag, type, is a Filter; no mop-up is needed, because I’ve exhausted the cases:

switch type {
case .albums:
    print("Albums")
case .playlists:
    print("Playlists")
case .podcasts:
    print("Podcasts")
case .books:
    print("Books")
}

A switch statement provides a way to extract an associated value from an enum case. Recall this enum from Chapter 4:

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

To extract the error number from an Error whose case is .number, or the message string from an Error whose case is .message, I can use a switch statement. Recall that the associated value is actually a tuple. A tuple of patterns after the matched case name is applied to the associated value. If a pattern is a binding variable, it captures the associated value. The let (or var) can appear inside the parentheses or after the case keyword; this code illustrates both alternatives:

switch err {
case .number(let theNumber):
    print("It is a number: \(theNumber)")
case let .message(theMessage):
    print("It is a message: \(theMessage)")
case .fatal:
    print("It is fatal")
}

If the let (or var) appears after the case keyword, I can add a where clause:

switch err {
case let .number(n) where n > 0:
    print("It's a positive error number \(n)")
case let .number(n) where n < 0:
    print("It's a negative error number \(n)")
case .number(0):
    print("It's a zero error number")
default:break
}

If I don’t want to extract the error number but just want to match against it, I can use some other pattern inside the parentheses:

switch err {
case .number(1...Int.max):
    print("It's a positive error number")
case .number(Int.min...(-1)):
    print("It's a negative error number")
case .number(0):
    print("It's a zero error number")
default:break
}

This same pattern also gives us yet another way to deal with an Optional tag. An Optional, as I explained in Chapter 4, is in fact an enum. It has two cases, .none and .some, where the wrapped value is the .some case’s associated value. But now we know how to extract the associated value! Thus we can rewrite yet again the earlier example where i is an Optional wrapping an Int:

switch i {
case .none: break
case .some(1):
    print("You have 1 thingy!")
case .some(let n):
    print("You have \(n) thingies!")
}

When all you want to do is extract an associated value from an enum, a full switch statement may seem a bit heavy-handed. The lightweight if case construct lets you use in a condition the same sort of pattern syntax you’d use in a case of a switch statement. Where a switch case pattern is compared against a previously stated tag, an if case pattern is followed by an equal sign and the tag. Thus, for example, this is another way to extract an associated value from an enum; err is our Error enum once again:

if case let .number(n) = err {
    print("The error number is \(n)")
}

The condition starting with case is a condition like any other, and can be part of a longer comma-separated condition list:

if case let .number(n) = err, n < 0 {
    print("The negative error number is \(n)")
}

To combine switch case tests (with an implicit logical-or), separate them with a comma:

switch i {
case 1,3,5,7,9:
    print("You have a small odd number of thingies.")
case 2,4,6,8,10:
    print("You have a small even number of thingies.")
default:
    print("You have too many thingies for me to count.")
}

In this example, i is declared as an Any:

switch i {
case is Int, is Double:
    print("It's some kind of number.")
default:
    print("I don't know what it is.")
}

New in Swift 3, a comma can even combine patterns that declare binding variables, provided they declare the same variable of the same type:

switch err {
case let .number(n) where n > 0, let .number(n) where n < 0:
    print("It's a nonzero error number \(n)")
case .number(0):
    print("It's a zero error number")
default:break
}

Another way of combining cases is to jump from one case to the next by using a fallthrough statement. When a fallthrough statement is encountered, the current case code is aborted immediately and the next case code runs unconditionally. The test of the next case is not performed, so the next case can’t declare any binding variables, because they would never be set. It is not uncommon for a case to consist entirely of a fallthrough statement:

switch pep {
case "Manny": fallthrough
case "Moe": fallthrough
case "Jack":
    print("\(pep) is a Pep boy")
default:
    print("I don't know who \(pep) is")
}

An interesting problem arises when you’d like to decide what value to use — for example, what value to assign to a variable. This seems like a good use of a branching construct. You can, of course, declare the variable first without initializing it, and then set it from within a subsequent branching construct. It would be nice, however, to use a branching construct as the variable’s value. Here, for example, I try (and fail) to write a variable assignment where the equal sign is followed directly by a branching construct:

let title = switch type { // compile error
case .albums:
    "Albums"
case .playlists:
    "Playlists"
case .podcasts:
    "Podcasts"
case .books:
    "Books"
}

There are languages that let you talk that way, but Swift is not one of them. However, an easy workaround does exist — use a define-and-call anonymous function, as I suggested in Chapter 2:

let title : String = {
    switch type {
    case .albums:
        return "Albums"
    case .playlists:
        return "Playlists"
    case .podcasts:
        return "Podcasts"
    case .books:
        return "Books"
    }
}()

In the special case where a value can be decided by a two-pronged condition, Swift provides the C ternary operator (:?). Its scheme is as follows:

condition ? exp1 : exp2

If the condition is true, the expression exp1 is evaluated and the result is used; otherwise, the expression exp2 is evaluated and the result is used. Thus, you can use the ternary operator while performing an assignment, using this schema:

let myVariable = condition ? exp1 : exp2

What myVariable gets initialized to depends on the truth value of the condition. I use the ternary operator heavily in my own code. Here’s an example:

cell.accessoryType =
    ix.row == self.currow ? .checkmark : .disclosureIndicator

The context needn’t be an assignment; here, we’re deciding what value to pass as a function argument:

context.setFillColor(self.hilite ? purple.cgColor : beige.cgColor)

The ternary operator can also be used to determine the receiver of a message. In this example, one of two UIViews will have its background color set:

(self.firstRed ? v1 : v2).backgroundColor = .red

In Objective-C, there’s a collapsed form of the ternary operator that allows you to test a value against nil. If it is nil, you get to supply a substitute value. If it isn’t nil, the tested value itself is used. In Swift, the analogous operation would involve testing an Optional: if the tested Optional is nil, use the substitute value; if it isn’t nil, unwrap the Optional and use the unwrapped value. Swift has such an operator — the ?? operator (called the nil-coalescing operator).

In this example, arr is a Swift array of Optional strings, and I’m converting it to a form that can be processed by a method written in Objective-C. An Objective-C NSArray can’t contain nil, so Cocoa provides a special class, NSNull, whose singleton instance, NSNull(), can stand in for nil where an object is needed. So I propose to unwrap those Optional strings that aren’t nil and substitute NSNull() for those that are. Here’s a perfectly effective implementation:

let arr2:[Any] = arr.map {if $0 != nil {return $0!} else {return NSNull()}}

But we can write the same thing much more neatly using the ternary operator:

let arr2 = arr.map {$0 != nil ? $0! : NSNull() as Any}

And the nil-coalescing operator is even neater:

let arr2 = arr.map {$0 ?? NSNull() as Any}

Expressions using ?? can be chained:

let someNumber = i1 as? Int ?? i2 as? Int ?? 0

That code tries to cast i1 to an Int and use that Int. If that fails, it tries to cast i2 to an Int and use that Int. If that fails, it gives up and uses 0.

A while loop comes in two forms, schematized in Example 5.3.

while condition {
    statements
}

repeat {
    statements
} while condition

The chief difference between the two forms is the timing of the test. In the second form, the condition is tested after the block has executed — meaning that the block will be executed at least once.

Usually, the code inside the block will change something that alters both the environment and the condition, thus eventually bringing the loop to an end. Here’s a typical example from my own code (movenda is an array):

while self.movenda.count > 0 {
    let p = self.movenda.removeLast()
    // ...
}

Each iteration removes an element from movenda, so eventually its count falls to 0 and the loop is no longer executed; execution then proceeds to the next line after the closing curly braces.

The first form of while loop can involve a conditional binding of an Optional. This provides a compact way of safely unwrapping an Optional and looping until the Optional is nil; the local variable containing the unwrapped Optional is in scope inside the curly braces. Thus, my code can be rewritten more compactly:

while let p = self.movenda.popLast() {
    // ...
}

There is no Swift repeat...until construct; instead, negate the while condition. In my own code, for example, I commonly need to walk my way up or down a hierarchy. Here, textField is a subview, at some depth, of some table view cell, and I want to know which table view cell it is a subview of. So I keep walking up the view hierarchy, investigating each superview in turn, until either I reach a table view cell or I hit the top of the view hierarchy:

var v : UIView? = textField
repeat {v = v?.superview} while !(v is UITableViewCell || v == nil)
if let c = v as? UITableViewCell {
    // ... if we get here, c is the cell
}

Similar to the if case construct, while case lets you use a switch case pattern. In this rather artificial example, we have an array of various Error enums:

let arr : [Error] = [
    .message("ouch"), .message("yipes"), .number(10), .number(-1), .fatal
]

We can extract the .message associated string values from the start of the array, like this:

var i = 0
while case let .message(message) = arr[i]  {
    print(message) // "ouch", then "yipes"; then the loop stops
    i += 1
}

The Swift for loop is schematized in Example 5.4.

for variable in sequence {
    statements
}

The for...in construct that forms the basis of Swift’s for loop is similar to Objective-C’s for...in construct. In Objective-C, this syntax is available whenever a class conforms to the NSFastEnumeration protocol. In Swift, it is available whenever a type adopts the Sequence protocol.

In the for...in construct, the variable is implicitly declared with let on each iteration; it is thus immutable by default. (If you need to assign to the variable within the block, write for var.) The variable is also local to the block. On each iteration, a successive element of the sequence is used to initialize the variable, which is then in scope inside the block.

A common use of for loops is to iterate through successive numbers. This is easy in Swift, because you can readily create a sequence of numbers on the fly — a Range:

for i in 1...5 {
    print(i)
}

Under the hood, a Sequence has a makeIterator method which yields an iterator object adopting IteratorProtocol. According to this protocol, the iterator has a mutating next method that returns the next object in the sequence wrapped in an Optional, or nil if there is no next object. Thus, for...in is actually a kind of while loop:

var g = (1...5).makeIterator()
while let i = g.next() {
    print(i)
}

Sometimes you may find that writing out the while loop explicitly in that way makes the loop easier to control and to customize.

The sequence will often be an existing value. It might be a character sequence, in which case the variable values are the successive Characters. It might be an array, in which case the variable values are the successive elements of the array. It might be a dictionary, in which case the variable values are key–value tuples, and you will probably express the variable as a tuple of two names in order to capture them. Many examples have already appeared in earlier chapters.

As I explained in Chapter 4, you may encounter an array coming from Objective-C whose elements will need to be cast down from Any. It is quite typical to do this as part of the sequence specification:

let p = Pep()
for boy in p.boys() as! [String] {
    // ...
}

The sequence enumerated method yields a succession of tuples preceding each element of the original sequence with its index number:

for (i,v) in self.tiles.enumerated() {
    v.center = self.centers[i]
}

If you need to skip some values of the sequence, you can append a where clause:

for i in 0...10 where i % 2 == 0 {
    print(i) // 0, 2, 4, 6, 8, 10
}

Like if case and while case, there’s also for case, letting us use a switch case pattern in a for loop. The tag is each successive value of the sequence, so no assignment operator is used. Return to our example of an array of Error enums:

let arr : [Error] = [
    .message("ouch"), .message("yipes"), .number(10), .number(-1), .fatal
]

Here we cycle through the whole array, extracting just the .number associated values:

for case let .number(i) in arr {
    print(i) // 10, -1
}

Similarly, here’s how to work safely with an array each of whose elements might or might not be castable to a certain type:

let arr : [Any] = ["hey", 1, "ho"]
for case let s as String in arr {
    print(s) // hey, ho
}

A sequence also has instance methods, such as map(_:), filter(_:), and reversed; you can apply these to hone the sequence through which we will cycle. In this example, I count backward by even numbers:

let range = (0...10).reversed().filter{$0 % 2 == 0}
for i in range {
    print(i) // 10, 8, 6, 4, 2, 0
}

Yet another approach is to generate the sequence by calling stride(from:through:by) or stride(from:to:by:). These are global functions whose first parameter must adopt the Strideable protocol, which is adopted by numeric types and anything else that can be incremented and decremented. Which form you use depends on whether or not you want the sequence to include the final value. The by: argument can be negative:

for i in stride(from: 10, through: 0, by: -2) {
    print(i) // 10, 8, 6, 4, 2, 0
}

For maximum flexibility, you can use the global sequence function (new in Swift 3) to generate your sequence by rule. It takes two parameters — an initial value, and a generation function that returns the next value based on what has gone before. In theory, the sequence generated by the sequence function can be infinite in length — though this is not a problem, because the resulting sequence is “lazy,” meaning that an element isn’t generated until you ask for it. In reality, you’ll use one of two techniques to limit the result. The generation function can limit the sequence by returning nil to signal that the end has been reached:

let seq = sequence(first:1) {$0 >= 10 ? nil : $0 + 1}
for i in seq {
    print(i) // 1,2,3,4,5,6,7,8,9,10
}

Alternatively you can request just a piece of the infinite sequence — for example, by cycling through the sequence for a while and then stopping, or by taking a finite prefix:

let seq = sequence(first:1) {$0 + 1}
for i in seq.prefix(5) {
    print(i) // 1,2,3,4,5
}

The sequence function comes in two forms. The first form, sequence(first:next:), initially hands first into the next: function and subsequently hands the previous result of the next: function into the next: function, as illustrated in the preceding examples. The second form, sequence(state:next:), is more general: it repeatedly hands state into the next: function as an inout parameter; the next: function is expected to set that parameter, using it as a scratchpad, in addition to returning the next value in the sequence. An obvious illustration is the Fibonacci sequence:

let fib = sequence(state:(0,1)) {
    (pair: inout (Int,Int)) -> Int in
    let n = pair.0 + pair.1
    pair = (pair.1,n)
    return n
}
for i in fib.prefix(10) {
    print(i) // 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
}

You can cycle through two sequences simultaneously using the global zip function, which takes two sequences and yields a Zip2Sequence struct, which is itself a sequence. The value on each iteration through a Zip2Sequence is a tuple of the corresponding elements from both original sequences; if one of the original sequences is longer than the other, the extra elements are ignored:

let arr1 = ["CA", "MD", "NY", "AZ"]
let arr2 = ["California", "Maryland", "New York"]
var d = [String:String]()
for (s1,s2) in zip(arr1,arr2) {
    d[s1] = s2
} // now d is ["MD": "Maryland", "NY": "New York", "CA": "California"]

One of the most important constructs in Swift is the function call (Chapter 2). One function calls another, which may call another, and so on, forming a call stack. When a return statement is encountered, accompanied by a return value if needed, execution of the function code is aborted immediately and the path of execution comes back to the point at which the call is made. In effect, we have jumped one level up the call stack.

Swift also has several ways of shortcircuiting the flow of branch and loop constructs:

When constructs are nested, you may need to specify which construct you want to continue or break. Therefore, Swift permits you to put a label before the start of a do block, an if construct, a switch statement, a while loop, or a for loop. The label is an arbitrary name followed by a colon. You can then use that label name as a second term in a continue or break statement within the labeled construct at any depth, to specify that this is the construct you are referring to.

Here’s an artificial example to illustrate the syntax. First, I’ll nest two for loops with no label:

for i in 1...5 {
    for j in 1...5 {
        print("\(i), \(j);")
        break
    }
}
// 1, 1; 2, 1; 3, 1; 4, 1; 5, 1;

As you can see from the output, that code keeps aborting the inner loop after one iteration, while the outer loop proceeds normally through all five iterations. But what if you wanted to abort the entire nested construct? The solution is a label:

outer: for i in 1...5 {
    for j in 1...5 {
        print("\(i), \(j);")
        break outer
    }
}
// 1, 1;

Sometimes a situation arises where further coherent progress is impossible: the entire operation in which we are engaged has failed. It can then be desirable to abort the current scope, and possibly the current function, and possibly even the function that called it, and so on, exiting to a point where we can acknowledge this failure and proceed in good order in some other way.

For this purpose, Swift provides a mechanism for throwing and catching errors. In keeping with its usual insistence on safety and clarity, Swift imposes certain strict conditions on the use of this mechanism, and the compiler will ensure that you adhere to them.

An error, in this sense, is a kind of message, presumably indicating what went wrong. This message is passed up the nest of scopes and function calls as part of the error-handling process, and the code that recovers from the failure can, if desired, read the message and determine how to proceed.

In Swift, an error must be an object of a type that adopts the Error protocol, which has just two requirements: a String _domain property and an Int _code property. The purpose of those properties is to help errors cross the bridge between Swift and Objective-C; in real life, you will be unaware of them (and in fact you won’t even see them listed in the Swift header). What you will see and use will be one of the following:

There are two stages of the error mechanism to consider: throwing an error, and catching an error. Throwing an error aborts the current path of execution and hands an error object to the error mechanism. Catching an error receives that error object from the error mechanism and responds in good order, with the path of execution resuming after the point of catching. In effect, we have jumped from the throwing point to the catching point.

To throw an error, use the keyword throw followed by an error object. That’s all it takes! The current block of code is immediately aborted, and the error mechanism takes over. However, to ensure that the throw command is used coherently, Swift imposes a rule that you can say throw only in a context where the error can be caught. What is such a context?

The primary context for throwing and catching an error is the do...catch construct. This consists of a do block and one or more catch blocks. It is legal to throw in the do block; an accompanying catch block can then be fed any errors thrown from within the do block. The do...catch construct’s schema looks like Example 5.5.

do {
    statements // a throw can happen here
} catch errortype {
    statements
} catch {
    statements
}

A single do block can be accompanied by multiple catch blocks. Catch blocks are like the cases of a switch statement, and will usually have the same logic: first, you might have specialized catch blocks, each of which is designed to handle some limited set of possible errors; finally, you might have a general catch block that acts as the default, mopping up any errors that were not caught by any of the specialized catch blocks.

In fact, the syntax used by a catch block to specify what sorts of error it catches is the pattern syntax used by a case in a switch statement! Imagine that this is a switch statement, and that the tag is the error object. Then the matching of that error object to a particular catch block is performed just as if you had written case instead of catch. Typically, when the Error is an enum, a specialized catch block will state at least the enum that it catches, and possibly also the case of that enum; it can have a binding, to capture the enum or its associated type; and it can have a where clause to limit the possibilities still further.

To illustrate, I’ll start by defining a couple of errors:

enum MyFirstError : Error {
    case firstMinorMistake
    case firstMajorMistake
    case firstFatalMistake
}
enum MySecondError : Error {
    case secondMinorMistake(i:Int)
    case secondMajorMistake(s:String)
    case secondFatalMistake
}

Now here’s a do...catch construct designed to demonstrate some of the different ways we can catch different errors in different catch blocks:

do {
    // throw can happen here
} catch MyFirstError.firstMinorMistake {
    // catches MyFirstError.firstMinorMistake
} catch let err as MyFirstError {
    // catches all other cases of MyFirstError
} catch MySecondError.secondMinorMistake(let i) where i < 0 {
    // catches e.g. MySecondError.secondMinorMistake(i:-3)
} catch {
    // catches everything else
}

In a catch block with an accompanying pattern, it is up to you to capture in the pattern any desired information about the error. For example, if you want the error itself to travel as a variable into the catch block, you’ll need a binding in the pattern. A catch block whose pattern is only a binding catches any error under that name; for example, catch let mistake is a “mop-up” catch block that catches any error and calls the error object mistake. In a “mop-up” catch block with no accompanying pattern, the error object arrives into the block automatically as a variable called error.

Thus, let’s look again at the previous example, but this time we’ll note whether and how the error object arrives into each catch block:

do {
    // throw can happen here
} catch MyFirstError.firstMinorMistake {
    // no error object, but we know it's MyFirstError.firstMinorMistake
} catch let err as MyFirstError {
    // MyFirstError arrives as err
} catch MySecondError.secondMinorMistake(let i) where i < 0 {
    // only i arrives, but we know it's MySecondError.secondMinorMistake
} catch {
    // error object arrives as error
}

However, as I said earlier, there’s something else that can happen to a thrown error; instead of being caught directly, it can percolate up the calling chain, leaving the current function and arriving at the point where this function was called. In this situation, the error won’t be caught here, at the point of throwing; it needs to be caught further up the calling chain. Moreover, suppose a do...catch construct lacks a “mop-up” catch block. Then a throw inside the do block might not be caught here, and again, the error will percolate up the calling chain, and needs to be caught further up the calling chain.

We therefore need a way to say to the compiler: “Look, I understand that it looks like this throw is not happening in a context where it can be caught, but that’s only because you’re not looking far enough up the calling chain. If you do look far enough, you’ll see that a throw at this point is eventually caught.” That way is the throws keyword.

If you mark a function with the throws keyword, then its entire body becomes a legal place for throwing. The syntax for declaring a throws function is that the keyword throws appears immediately after the parameter list (and before the arrow operator, if there is one) in the function’s declaration. For example:

enum NotLongEnough : Error {
    case iSaidLongIMeantLong
}
func giveMeALongString(_ s:String) throws {
    if s.characters.count < 5 {
        throw NotLongEnough.iSaidLongIMeantLong
    }
    print("thanks for the string")
}

The addition of throws to a function declaration creates a distinct function type. The type of giveMeALongString is not (String) -> (), but rather (String) throws -> (). If a function receives as parameter a function that can throw, that parameter’s type needs to be specified accordingly:

func receiveThrower(_ f:(String) throws -> ()) {
    // ...
}

That function can now be called with giveMeALongString as argument:

func callReceiveThrower() {
    receiveThrower(giveMeALongString)
}

An anonymous function, if necessary, can include the keyword throws in its in line, in the same place where it would appear in a normal function declaration. But this is not necessary if, as is usually the case, the anonymous function’s type is known by inference:

func receiveThrower(_ f:(String) throws -> ()) {
    // ...
}
func callReceiveThrower() {
    receiveThrower {
        s in // can say "s throws in", but not required
        if s.characters.count < 5 {
            throw NotLongEnough.iSaidLongIMeantLong
        }
        print("thanks for the string")
    }
}

Swift also imposes a requirement on the caller of a throws function: the caller must precede the call with the keyword try. This keyword acknowledges, to the programmer and to the compiler, that this function can throw. But since this function can throw, there is a further requirement: this call must take place where throwing is legal! A function called with try can throw, so saying try is just like saying throw: you must say it either in the do block of a do...catch construct or in the body of a throws function.

So, for example:

func stringTest() {
    do {
        try giveMeALongString("is this long enough for you?")
    } catch {
        print("I guess it wasn't long enough: \(error)")
    }
}

But Swift also provides a clever shorthand. If you are very sure that a throws function will in fact not throw, then you can call it with the keyword try! instead of try. This relieves you of all further responsibility: you can say try! anywhere, without catching the possible throw. But be warned: if you’re wrong, and this function does throw when your program runs, your program can crash at that moment, because you have allowed an error to percolate, uncaught, all the way up to the top of the calling chain.

Thus, this is legal but dangerous; we are calling a throws function not in a do...catch block and not in another throws function, and telling the compiler to trust us and let us do it:

func stringTest() {
    try! giveMeALongString("okay")
}

In between try and try! is try?. This has the advantage that, like try!, you can use it anywhere; but, like a do...catch construct, it catches the throw if there is one, without crashing. If there’s a throw, you don’t receive any error information, as you would with a catch block; but try? tells you if there was a throw, by returning nil. Thus, try? is useful particularly in situations where its expression returns a value. If there’s a throw, it returns nil. If there’s no throw, it wraps the returned value in an Optional. Commonly, you’ll unwrap that Optional safely in the same line with a conditional binding. I’ll give an example in a moment.

Even if your own code never uses the keyword throw explicitly, you’re still very likely, in real life, to call Cocoa methods that are marked with throws. Therefore, you need to know how Swift’s error mechanism relates to Cocoa and Objective-C. Recall that an Objective-C method can return only one value (there are no tuples). So if a Cocoa method that returns a value has a failure and wants to hand back an NSError, how can it do it? The answer is that such a method will return nil to indicate failure, and will also take an NSError** parameter as a way of communicating an error to the caller in addition to the method result; the NSError** parameter is similar to a Swift inout parameter.

For example, NSString has an initializer declared in Objective-C like this:

- (instancetype)initWithContentsOfFile:(NSString *)path
                              encoding:(NSStringEncoding)enc
                                 error:(NSError **)error;

Objective-C code that calls that initializer must test to see whether the resulting NSString is in fact nil, and can examine the resulting error if it is:

NSError* err;
NSString* s =
    [[NSString alloc] initWithContentsOfFile:f
                                    encoding:NSUTF8StringEncoding
                                       error:&err];
if (s == nil) {
    NSLog(@"%@", err);
}

As you can see, the whole procedure is a lot like using a Swift inout parameter. An NSError variable must be prepared beforehand, and its address must be passed as the error: argument. Then we have to test the result for nil explicitly, to see whether the initialization succeeded. This is an annoyingly elaborate but necessary dance in Objective-C, and in Swift, prior to Swift 2.0, the dance was effectively the same.

In modern Swift, however, there’s a different dance — a much simpler, more pleasant one. Such an Objective-C method is automatically recast to take advantage of the error mechanism. The error: parameter is removed from the Swift translation of the declaration, and is replaced by a throws marker:

init(contentsOfFile path: String, encoding enc: String.Encoding) throws

Thus there is no need to declare an NSError variable beforehand, and no need to receive the NSError by indirection. Instead, you just call the method, within the controlled conditions dictated by Swift. And what are those conditions? One way is to say try, in a place where throwing is legal. The result in that case can never be nil; it’s a String, plain and simple, because if the initialization fails, the call will throw and no result will arrive at all. Here’s an example (the encoding: parameter is optional, and defaults to .utf8):

do {
    let f = // path to some file, maybe
    let s = try String(contentsOfFile: f)
    // ... if successful, do something with s ...
} catch {
    print(error.localizedDescription)
}

Alternatively, you’re very sure the initialization won’t fail, you can skip the do...catch construct and use try! instead; again, the result can never be nil, so it’s just a String:

let f = // path to some file, maybe
let s = try! String(contentsOfFile: f)

Finally, you can skip the do...catch construct and still proceed safely by using try?, in which case the value returned is an Optional wrapping a String, which you can test for nil to learn whether the initialization succeeded. You’ll probably unwrap the Optional safely at the same point where you make the call, like this:

let f = // path to some file, maybe
if let s = try? String(contentsOfFile: f) {
    // ...
}

Objective-C NSError and Swift Error are bridged to one another. Thus, in a catch block a moment ago, I examined the error variable using an NSError property. Moreover, you can catch the specific NSError by its name. The name you’ll use is the NSError domain, and optionally (with dot-notation) the Cocoa name of its code.

For example, let’s say we call init(contentsOfFile:) and we want specifically to catch the error thrown when there is no such file. This NSError’s domain, according to Cocoa, is "NSCocoaErrorDomain"; Swift sees that as CocoaError. Its code is 260, for which Cocoa provides the name NSFileReadNoSuchFileError (I found that out by looking in the FoundationErrors.h header file in Objective-C); Swift sees that as .fileReadNoSuchFile. Thus we can catch this specific error under the name CocoaError.fileReadNoSuchFile, like this:

do {
    let f = // path to some file, maybe
    let s = try String(contentsOfFile: f)
    // ... if successful, do something with s ...
} catch CocoaError.fileReadNoSuchFile {
    print("no such file")
} catch {
    print(error)
}

Objective-C sees a Swift error coherently as well. It receives a Swift error as an NSError whose domain is the name of the Swift object type. If the Swift object type is an enum, the NSError’s code is the index number of its case; otherwise, the code is 1.

func receiveThrower(_ f:(String) throws -> ()) rethrows {
    try f("ok?")
}
func callReceiveThrower() { // no throws needed
    receiveThrower { // no try needed
        s in
        print("thanks for the string!")
    }
}

Sometimes, when you know that a local variable needs to exist only for a few lines of code, you might like to define an artificial scope — a custom nested scope, at the start of which you can introduce your local variable, and at the end of which that variable will be permitted to go out of scope, destroying its value automatically.

Swift, however, does not permit you to use bare curly braces to do this. Instead, use a bare do construct without a catch:

do {
    var myVar = "howdy"
    // ... use myVar here ...
}
// now myVar is out of scope and its value is destroyed

The purpose of the defer statement is to ensure that a certain block of code will be executed at the time the path of execution flows out of the current scope, no matter how.

A defer statement applies to the scope in which it appears, such as a function body, a while block, an if construct, a do block, and so on. Wherever you say defer, curly braces surround it somehow; the defer block will be executed when the path of execution leaves those curly braces. Leaving the curly braces can involve reaching the last line of code within the curly braces, or any of the forms of early exit described earlier in this section.

To see why this is useful, consider the following pair of commands:

It can be valuable to turn off user interactions at the start of some slightly time-consuming operation and then turn them back on after that operation, especially when, during the operation, the interface or the app’s logic will be in some state where the user’s tapping a button, say, could cause things to go awry. Thus, it is not uncommon for a method to be constructed like this:

func doSomethingTimeConsuming() {
    UIApplication.shared.beginIgnoringInteractionEvents()
    // ... do stuff ...
    UIApplication.shared.endIgnoringInteractionEvents()
}

All well and good — if we can guarantee that the only path of execution out of this function will be by way of that last line. But what if we need to return early from this function? Our code now looks like this:

func doSomethingTimeConsuming() {
    UIApplication.shared.beginIgnoringInteractionEvents()
    // ... do stuff ...
    if somethingHappened {
        return
    }
    // ... do more stuff ...
    UIApplication.shared.endIgnoringInteractionEvents()
}

Oops! We’ve just made a terrible mistake. By providing an additional path out of our doSomethingTimeConsuming function, we’ve created the possibility that our code might never encounter the call to endIgnoringInteractionEvents. We might leave our function by way of the return statement — and the user will then be left unable to interact with the interface. Obviously, we need to add another endIgnoring... call inside the if construct, just before the return statement. But as we continue to develop our code, we must remember, if we add further ways out of this function, to add yet another endIgnoring... call for each of them. This is madness!

The defer statement solves the problem. It lets us specify once what should happen when we leave this scope, no matter how. Our code now looks like this:

func doSomethingTimeConsuming() {
    defer {
        UIApplication.shared.endIgnoringInteractionEvents()
    }
    UIApplication.shared.beginIgnoringInteractionEvents()
    // ... do stuff ...
    if somethingHappened {
        return
    }
    // ... do more stuff ...
}

The endIgnoring... call in the defer block will be executed, not where it appears, but before the return statement, or before the last line of the method — whichever path of execution ends up leaving the function. The defer statement says: “Eventually, and as late as possible, be sure to execute this code.” We have thus ensured the necessary balance between turning off user interactions and turning them back on again. Most uses of the defer statement will probably come under this same rubric: you’ll use it to balance a command or restore a disturbed state.

Observe that in the preceding code, I placed the defer block very early in its surrounding scope, even though this caused the endIgnoring... call to precede visually the beginIgnoring... call that it balances. This placement is important because a defer block is itself, as a whole, executable code. If a defer block is not actually encountered by the path of execution before we exit from the surrounding scope, it won’t be executed. For this reason, always place your defer block as close to the start of its surrounding block as you can, to ensure that it will in fact be encountered.

Aborting the whole program is an extreme form of flow control; the program stops dead in its tracks. In effect, you have deliberately crashed your own program. This is an unusual thing to do, but it can be useful as a way of raising a very red flag: you don’t really want to abort, so if you do abort, things must be so bad that you’ve no choice.

One way to abort is by calling the global function fatalError. It takes a String parameter permitting you to provide a message to appear in the console. I’ve already given this example:

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

That code says, in effect, that execution should never reach this point. We have declared init(coder:) just because it is required, and we need to satisfy the compiler; but we have no real implementation of init(coder:), and we do not expect to be initialized this way. If we are initialized this way, something has gone very wrong, and we want to crash, because our program has a serious bug.

An initializer containing a fatalError call does not have to initialize any properties. This is because fatalError is declared as returning Never, which causes the compiler to abandon any contextual requirements. Similarly, a function that returns a value does not have to return any value if a fatalError call is encountered.

You can also abort conditionally by calling the assert function. Its first parameter is a condition — something that evaluates as a Bool. If the condition is false, we will abort; the second parameter is a String message to appear in the console if we do abort. The idea here is that you are making a bet (an assertion) that the condition is true — a bet that you feel so strongly about that if the condition is false, there’s a serious bug in your program and you want to crash so you can learn of this bug and fix it.

By default, assert works only when you’re developing your program. When your program is to be finalized and made public, you throw a different build switch, telling the compiler that assert should be ignored. In effect, the conditions in your assert calls are then disregarded; they are all seen as true. This means that you can safely leave assert calls in your code. By the time your program ships, of course, none of your assertions should be failing; any bugs that caused them to fail should already have been ironed out.

The disabling of assertions in shipping code is performed in an interesting way. The condition parameter is given an extra layer of indirection by declaring it as an @autoclosure function. This means that, even though the parameter is not in fact a function, the compiler will wrap it in a function; thus, the runtime needn’t call that function unless it has to. In shipping code, the runtime will not call that function. This mechanism averts expensive and unnecessary evaluation: an assert condition test may involve side effects, but the test won’t even be performed when assertions are turned off in your shipping program.

In addition, Swift provides the assertionFailure function. It’s like an assert that always fails — and, like an assert, it doesn’t fail in your shipping program where assertions are turned off. It’s a convenient synonym for assert(false), as a way of assuring yourself that your code never goes where it’s never supposed to go. By contrast, precondition and preconditionFailure are similar to assert and assertionFailure, except that they do fail even in a shipping program.

If the need for jumping might arise, you will probably want to test a condition that decides whether to jump. Swift provides a special syntax for this situation — the guard statement. In effect, a guard statement is an if statement where you must exit early in response to failure of the condition. Its form is shown in Example 5.6.

guard condition else {
    statements
    exit
}

A guard statement, as you can see, consists solely of a condition and an else block. The else block must jump out of the current scope, by any of the means that Swift provides, such as return, break, continue, throw, or fatalError — anything that guarantees to the compiler that, in case of failure of the condition, execution absolutely will not proceed within the block that contains the guard statement.

An elegant consequence of this architecture is that, because the guard statement guarantees an exit on failure of the condition, the compiler knows that the condition has succeeded after the guard statement if we do not exit. Thus, a conditional binding in the condition is in scope after the guard statement, without introducing a further nested scope. For example:

guard let s = optionalString else {return}
// s is now a String (not an Optional)

A series of guard statements, as I demonstrated earlier, can be a nice alternative to the “pyramid of doom”:

override func observeValue(forKeyPath keyPath: String?,
    of object: Any?, change: [NSKeyValueChangeKey : Any]?,
    context: UnsafeMutableRawPointer?) {
        guard keyPath == readyForDisplay else {return}
        guard let obj = object as? AVPlayerViewController else {return}
        guard let ok = change?[.newKey] as? Bool else {return}
        guard ok else {return}
        // ...
}

A guard statement will also come in handy in conjunction with try?. Let’s presume we can’t proceed unless String(contentsOfFile:) succeeds. Then we can rewrite our earlier example like this:

let f = // path to some file, maybe
guard let s = try? String(contentsOfFile: f)
    else {return}
// s is now a String (not an Optional)

There is also a guard case construct, forming the logical inverse of if case. To illustrate, we’ll use our Error enum once again:

guard case let .number(n) = err else {return}
// n is now the extracted number

guard case helps to solve an interesting problem. Suppose we have a function whose returned value we want to check in a guard statement:

guard howMany() > 10 else {return}

All well and good; but suppose also that in the next line we want to use the value returned from that function. We don’t want to call the function again; it might be time-consuming and it might have side effects. We want to capture the result of calling the function and pass that captured result on into the subsequent code. But we can’t do that with guard let, because that requires an Optional, and our function doesn’t return an Optional.

What should we do? Well, we could wrap the returned value from our function in an Optional just so we can unwrap it again:

guard let output = Optional(howMany()), output > 10 else {return}
// now output is in scope (not an Optional)

That happens to work, but it’s horrible. guard case to the rescue:

guard case let output = howMany(), output > 10 else {return}
// now output is in scope

Note that a guard statement’s conditional binding can’t use on the left side of the equal sign a name already declared in the same scope. This is illegal:

let s = // ... some Optional
guard let s = s else {return} // compile error

The reason is that guard let, unlike if let and while let, doesn’t declare the bound variable for a nested scope; it declares it for this scope. Thus, we can’t declare s here because s has already been declared in the same scope.