- General Changes
- Loops
- Conditionals
- To Integers and Beyond!
- Wrapping Up
This chapter is from the book
This chapter is from the book
This chapter is from the book
To Integers and Beyond!
While switch statements have always been useful for dealing with integers, if you couldn’t boil your data down to numbers, you had to move back to clunkier if constructs, which has long been a source of frustration for developers.
Strings
Quite possibly one of the most sought after capabilities is that of being able to match against strings. A common pattern in Objective-C is:
Using Swift, this boils down to:
While the length of the two alternatives is not significantly different, the need to state the stringValue variable just once makes refactoring easier and safer, and the Swift code block is arguably easier to comprehend while scanning the code.
Enumerations
Of course in Objective-C, switching based on the value of an enum is an integral part of development; after all, an Objective-C enum is nothing more than a “coded” integer, and all switch understands is integers.
However, over in the enlightened world of Swift, enumerations are now an object type, and thus no longer have to be plain old integers. We will look at enumerations in detail in Chapter 10, but for now all you need to know is that the underlying value can be as simple as an integer or as complex as a structure, an object, or even nothing at all! Thankfully Swift has you covered.
iOS developers who have worked with table views will be familiar with the UITableViewCellAccessoryType enumeration. If you wanted to check the value of the cell accessory type and perform different behaviors based on the value, you can do the following:
Ranges
One area in Objective-C where the if statement had the advantage over switch was number ranges. If you wanted to execute different code based on more than individual values, if was your only option. For example:
Earlier in this chapter, we looked at the concept of number ranges and in particular the half-open and closed ranges that Swift gives us. Using ranges and a switch statement you could easily reimplement this in Swift as:
You can also use switch statements with Swift’s other primitive types, including floating point numbers, optionals, and even object types. If you are in doubt about using a type with a switch statement, just create a new playground and try it out. And if you’re having no luck, there’s always pattern matching.
Pattern Matching
In Chapter 3, we briefly covered the pattern match operator (~=) and specifically mentioned that it could be used to great effect with switch statements. The pattern match operator is even implicitly added to your conditional statement. There are a number of different pattern types you can match with, and you’ve already looked at ranges in the previous section. Here, we will examine some more types, including tuples and wildcards, as well as looking at where clauses and value binding.
Tuples
As you learned in Chapter 3, a tuple is a simple set of ordered data such as a pair of coordinates, a list of places, or a sequence of numbers. Because tuples do not need to be defined in advance, you can assemble them from disparate pieces of data to make complex logic decisions. As an example, consider the following piece of code for customizing UITableViewCells based on their position in the table view:
At the minute, it isn’t too hard to follow, but with time and an expanding feature set, this set of nested if statements will start to become harder to read, debug, and maintain. You could reimplement this as a flatter structure using Swift’s ability to match on tuples:
This solution has the advantage of being visually flatter. Unfortunately, it isn’t as maintainable; the addition of new rows and sections will require constant updates. The conditional logic of the if statements, and particularly the else blocks, are sorely missing. Luckily there is an answer in the form of wildcards.
Wildcards
You first encountered the wildcard pattern very briefly in the previous section on for loops where you used a wildcard to discard the values you were iterating over. The wildcard pattern can also be used with tuples and case statements to match an entire series of entries with one statement. The wildcard operator (_) can be used in any position in the tuples supplied to a case statement, meaning you can match logical groupings like table sections.
When using the wildcard operator, bear in mind that if multiple case statements result in a match, the first case is the selected match; if we had placed the last entry (with the double wildcard) anywhere else, it would have a negative impact on the logic. Try to order your case statements from most to least specific, regardless of what type of pattern matching you use!
While this code is more readable, an unfortunate bit of duplication exists in the handling of rows 3, 4, and 5 in section 2. Swift allows you to use ranges in combination with tuples and wildcards. You can refactor the code to a more manageable version by using a range for handling rows 3, 4, and 5. The highlighted line in the following code replaces three case statements:
Value Bindings
Within conditional statements you often want to have access to the values used to make the decisions. Continuing with the table view cell customization example, you might actually want to know the row and section numbers handled by the wildcard patterns in the last case, the use case being that you want to display the number of the row and section in the cell.
Of course, these values are already available in the form of indexPath.row and indexPath.section, but Swift and UIKit still use the concept of zero-based indexes, which isn’t conducive to a good user experience. Creating new values based on the indexPath as part of the case statement block is possible, but you can also use a feature of Swift called value bindings; these allow values from the case to be bound to temporary variables or narrowly scoped constants.
You can now rewrite the last case statement to take advantage of value bindings:
By assigning to a variable, you are able to modify the section without worrying about changing the original tuple passed to the switch statement.
Note that the wildcard operators are no longer included in the case statement, but it still retains the same behavior. Think of the wildcard operator as a throwaway variable you do not care about; the value bindings, on the other hand, signify that you are interested in the values they contain.
Where Clauses
As if using tuples, ranges, and even wildcards didn’t give enough flexibility already, Swift adds even more capability by providing the facility to include where clauses in the case statement.
Another common use case when working with table views is the need to place some sort of highlight on a cell to indicate state, often through the use of color or a checkmark disclosure indicator. In our seemingly never-ending example, the sections of the table covered by the last case statement could have a highlight if their index paths are in a separately maintained array of index paths.
You could achieve this using nested conditional statements within the last case. Alternatively, you can make a copy of the case and use a where clause on the first one; remember, you want the case statements to go from most to least specific. A where clause takes a regular conditional expression, and it can use variables and constants from outside the switch statement as well as value bindings from within the case statement itself.
Using a where clause, the code now becomes:
Custom Pattern Matching
There will always be a use case the developers of Swift cannot foresee, and so they have provided the ability to create custom pattern matching behavior by overloading the pattern match (~=) operator. If you wanted to compare a String object to an Int, or one custom type to another, you will need to supply your own way of comparing the two types. For more information on operator overloading, see Chapter 14.
Safety Features
The improvements to switch are not just about usability; the efforts to make Swift a safer programming language have extended to the switch statement as well.
- No fall through by default: This is a fundamental change between the Objective-C and Swift behaviors. If you look at any of the examples in this chapter, you’ll notice that none of them feature a break statement. Unlike C and Objective-C, Swift does not allow code to fall through from one case statement to another by default: You have to explicitly request this behavior by adding the fallthrough keyword to the end of your case block. C and Objective-C developers are often bitten by the accidental omission of a break statement, but this rarely caused an actual error—just time spent debugging strange data problems.
Multiple conditions can apply to a single case: Now that relying on automatic fall through isn’t possible, multiple case conditions can be grouped on one or more lines when separated by commas. If you wanted to match on the values 1, 3, and 5, you can use case 1, 3, 5:. This is more efficient than putting successive lines doing something like the following code sample. This sample is legal but dangerous in Swift—accidentally removing the fallthrough keyword on one line may break a number of conditions.
- The case list must be exhaustive: In Swift, writing a switch statement where none of the supplied case statements are a match isn’t possible. If the compiler detects that such a condition has arisen, it reports an error. You can avoid this scenario by ensuring that you create case statements for every possible value, or set of values, by using wildcards or by including a default case.