Be Concise

The first thing I noticed about Swift was the lack of semicolons. I must admit that at that point I wrinkled my nose at it and thought “But, but, but . . . Why?!”

The thing is, Swift doesn’t stop you from using semicolons. But it doesn’t require you to use them either, unless you put separate statements on the same line. This underpins part of Swift’s philosophy: you can write code as verbose as you need it, but you also have the option to be as concise as humanly possible.

I say “humanly possible,” because the trouble with conciseness is not a compiler’s problem: if a shortcut is legal, the compiler will understand it. However, both writing code that is too verbose and writing code that is too brief can interfere with human readability, so exercise your judgment.

Here is an example: the two pieces of code in Listing 17-1 and Listing 17-2 are both valid Swift and both do exactly the same: they define an array of integers and obtain a sorted copy of it.

Listing 17-1. Sorting an Integer Array: Verbose

let arrayOfInts: Array<Int> = [6, 3, 4];
let sortedArray: Array<Int> = arrayOfInts.sort(
    { (item1: Int, item2: Int) -> Bool in return item1 < item2 } );

Listing 17-2. Sorting an Integer Array: Concise

let arrayOfInts = [6, 3, 4]
let sortedArray = arrayOfInts.sort(<)

The rest of the chapters in Part IV will explain what is going on with the code in Listings 17-1 and 17-2. For the missing type declarations in Listing 17-2 see the section “Type safety and Type Inference” in Chapter 19 . For the syntax in the function within the brackets in the first example and how it got reduced to a single operator in the second example see the section “Closures” in Chapter 22 . To find out what the let keyword means see the section “Declaring Variables and Constants,” later in this chapter. As for the missing semicolons . . . get over it. That’s how it is in Swift.

Be Explicit

One of the dangers of getting carried away with conciseness is ambiguity: you may end up writing code that is syntactically valid but doesn’t actually do what you meant it to do. For example, in most other languages it is too easy to swap two arguments of the same type by mistake: the code will compile, it will look convincing to the human eye and the mistake will only come to bite you as a bug later on, maybe even after you have shipped the code. (To see how Swift can help with this issue, see the section “Defining and Calling Functions” later in this chapter.)

To say that Swift encourages you to be explicit would be an understatement. It’s more like your grandmother who lovingly, but with some force, nudged you to say “please” and “thank you” to her neighbors. The Swift compiler nudges you in a similar way to state your intentions with every line of code you write.

For example, the ActionScript equivalent of the code in Listing 17-3 would result in all three print calls being executed, because I didn’t put a break statement after each case. In Swift this is not the default behavior: to get execution to continue to the next case statement whether there is a break or not, even if a match has been found, I would need to use the fallthrough keyword.

In fact, the code in Listing 17-3 will not compile. While in other languages you may not even get a warning if you omit the default clause in a switch statement , in Swift this causes a compilation error. For details on what else switch statements can do for you (there is a lot!) see Chapter 20 .

Listing 17-3. Spot the Missing Statement. Hint: It Is Not a break

let direction = 3

switch direction {
    case 1: print("Go South")
    case 2: print("Go North")
    case 3: print("Go East")
}

The effect of having to be explicit is twofold:

• You are less likely to suffer from bugs caused by accident and which, unfortunately, make for lexically valid code. For example, in Swift you can’t unintentionally put the assignment operator (=) where you meant to use the equality operator (==) (more on this in Chapter 18 ).

• By writing code that explicitly states what you mean, you end up with self-documented code and less need for comments that are (a) never read and (b) by definition out of date with the code they explain.

Take Advantage of the Compiler

In his invaluable work,¹ Steve Maguire talks about a hypothetical compiler, which would catch bugs for you. His book helps C developers get as close possible to this dream by teaching techniques that help the compiler help you (among other things) by adopting certain coding habits—for example, putting the (more) constant value on the left of the equals operator (==), so that the compiler can shout at you if you accidentally used the assignment operator (=).

Although a lot of bugs you will encounter are not possible to catch at compile time, Swift’s compiler comes close to Steve Maguire’s dream² and makes it almost impossible to default to bad habits.

A lot of what would be compiler warnings show up as errors in Swift. As likely as this is to irritate you initially,³ you will probably be grateful in the long run, as you will have adopted good coding habits and the maintenance of your apps costs you a lot less for lack of easily preventable bugs.

Syntax

If you grew up speaking Objective-C, you were probably used to its bulky syntax and it didn’t bother you very much. Transitioning to it from a language like ActionScript, however, was initially an exercise in learning how to read. In contrast, Swift does read a lot like ActionScript in how you define or access things.

With that said, Swift is not ActionScript and there are a couple of things that might seem obscure at first:

• The Optional type: you have likely noticed a lot of exclamation and question marks in Swift tutorials and in the examples in the other parts of this book. Chapter 19 demystifies their use and shows you how optionals can make your life easier.

• Conciseness, whose praises we sang earlier, can be a double-edged sword. It is a wonderful thing to be able to keep your statements short and clutter-free, but for a newcomer the second line, shown in Listing 17-2, may seem like a syntax error at first. Practice will help you with this: as Swift doesn’t force you to be brief, you can initially opt for the long syntax and gradually transition to omitting bits of code that the compiler can infer and that you can too.

Programming Concepts

Swift uses most of the programming concepts with which you are already familiar, including the object-oriented programming paradigm. A big part of your transition from ActionScript will be in the spirit of “Right. How do I bend a spoon in Swift?,” rather than having to first bend your mind around the thought that “There is no spoon,”⁴ as you might do if you were migrating to, say, a functional language.

If Swift were exactly the same as ActionScript, though, it would probably have been called ActionScript and not Swift, so be prepared for corners where we will need to shed light. Some of these are explained in context:

• Operator overloading in Chapter 18

• Optionals and tuples in Chapter 19

• Using labels in Chapter 20

• Deinitialization for classes in Chapter 21

• Structures in Chapter 21

To a few ideas, which might need a deeper looking into, we have dedicated a separate chapter (Chapter 22 ).

Memory Management

ActionScript uses both garbage collection (GC) and automatic reference counting (ARC) to manage memory, though the latter is not spoken of very much. A garbage collector may do a good job of finding cyclic references and freeing up memory that otherwise may have leaked, but you are not in control of when it kicks in and this can hurt performance. Over time, ActionScript developers have come up with hacks and workarounds to get some control over when GC is performed.

Swift classes use ARC , so you should be on familiar ground there. Moreover, as this is not a garbage-collected language, you will have control over when instances are deallocated. And, unlike moving to Objective-C, you will not have to get your head around pointers.

Swift also helps you be more mindful about how you use memory, as it distinguishes between reference types and value types (more on that in Chapter 21).

Declaring Variables and Constants

The first thing you are likely to ask when faced with the blank page, all right, screen, is: how do I declare a variable? Use the var keyword to declare a variable and the let keyword to declare a constant (Listing 17-6).

Listing 17-6. Declaring Variables and Constants

var anIntegerVariable = 10
let aStringConstant = "I am a string. And I am constant."

A nice thing about the Swift compiler is that it encourages you to use constants instead of variables wherever possible: if you declare a variable, but never change its value, you will get a warning like the one in Figure 17-2 suggesting that you change it to a constant by replacing var with let.

Figure 17-2. The compiler encourages the use of let wherever possible

Listing 17-6 shows you how to declare variables and constants in the spirit of conciseness: you can see that I have omitted the type declarations of anIntegerVariable and aStringContant. You can include them as you do in ActionScript, following a colon after the name of the variable, as in Listing 17-7.

Listing 17-7. Explicitly adding type declarations

var anIntegerVariable: Int = 10
let aStringConstant: String = "I am a string. And I am constant."

In the spirit of explicitness, however, Swift will not let you use the line in Listing 17-8, which is possible in ActionScript.

Listing 17-8. This Line Will Compile in ActionScript, But Not in Swift

var aVariable;

The Swift compiler is clever, but it will not tolerate not knowing the type of aVariable. For it to work it out you need to either state it explicitly or assign a value, from which the type can be inferred.

Making Comments

You add comments in Swift the same way you do in ActionScript. Use two forward slashes to prefix single-line comments:

// This is a single-line comment.

Put multiline comments inside the familiar forward-slash-plus-asterisk and asterisk-plus-forward-slash combination:

/* This is a comment,
which spans multiple lines. */

Printing in the Console

In Swift you can print diagnostic information in Xcode’s console with the print function, much like you do with trace in ActionScript. You can use print with any expression: to print it out as part of a string literal, put the expression in parentheses inside the string quotes and prefix it with a backslash () as shown in Listing 17-9:

Listing 17-9. Printing Out a Value in the Console

print(anIntegerVariable)
// output: 10

print("The value of anIntegerVariable is (anIntegerVariable).")
// output: The value of anIntegerVariable is 10.

For more details on inserting values in string literals and using escape sequences see the section “Strings” in Chapter 19 .

Defining and Calling Functions

To define a function, use the func keyword, followed by the name of the function, followed by a comma-separated argument list in parentheses and, if the function returns a result, add a return arrow (->), followed by the type of the result (Listing 17-10). If your function does not return a result, you don’t need to add anything after the closing parenthesis of the argument list. For functions that don’t take arguments you still need the parentheses after the function name, though their argument list will be empty.

Listing 17-10. Defining Functions in Swift

func divide(a: Double, b: Double) -> Double {
    return a / b
}

func printAQuote(quote: String, byAuthor: String) {
    print("'(quote)' 
(byAuthor)")                                                            
}

// Add explicit external argument names
func divide(dividend a: Double, divisor b: Double) -> Double {
    return a / b
}

// Label your arguments with their external names when making a call:
divide(dividend: 1, divisor: 0)

printAQuote("Life is too short to remove USB safely.",
             fromAuthor: "Anonymous")

func modifyMyString(inout str: String) {
    str = "Ha! I can override you!"
    print(str)
}

var myStr = "I am the boss."
modifyMyString(&myStr)
// Output: "Ha! I can override you!"

print(myStr)
// Output: "Ha! I can override you!"

func modifyMyString(var str: String) {
    str = "Ha! I can override you!"
    print(str)
}

var myStr = "I am the boss."
modifyMyString(myStr)
// Output: “Ha! I can override you!”

print(myStr)
// Output: "I am the boss."

func findMaximum(numbers: Int...) -> Int {
    var maxNum = Int.min
    for number in numbers {
        if number > maxNum {
            maxNum = number
        }
    }

    return maxNum
}

findMaximum(300, 4, 99) // returns 300

func printAQuote(quote: String, byAuthor: String = "Anonymous") {
    print("'(quote)' 
(byAuthor)")
}

// You can skip the byAuthor argument, as it has a default value:
printAQuote("Sm;)e")

func printInfo(i: Int) {
    print("Here is an integer: (i)")
}

func printInfo(s: String) {
    print("Here is a string: '(s)'")
}

func printInfo(i: Int, s: String) {
    print("Here is an integer: (i) and a string: '(s)'")
}

printInfo(3) // Calls the first function
printInfo("Ta-da!") // Calls the second function
printInfo(40, s: "Ali Baba's thieves") // Calls the third function

Access Control Rules

You have already seen from the tutorials in this book how you can structure your projects and that Swift code goes into .swift files. These files and the modules they form are the basis of defining how code is accessed. Here module is meant as a bunch of files you build and ship together as an application or as a framework.

There are three levels of access, which determine the visibility of a piece of code:

• private entities are only visible to code in the same file where they were defined.

• internal bits of code are accessible from source files inside the same module.

• public entities are accessible everywhere within the same module, as well as to code that uses it. They define the interface to the module.

In the previous definitions I use entities as a substitute for “almost anything you can define”: global variables, constants, and functions; classes, structures, and enumerations, as well as their members; and also protocols. The access modifiers can be applied to all these. The members of a protocol are an exception: you can define a private protocol but you cannot define its members as private.

The default access level is internal and is applied if you don’t explicitly provide an access modifier when you declare an entity.

If you are wondering “How about protected?,” the answer is that it doesn’t exist in Swift. To find out why see Chapter 21 . This is also where we you can find information on structures and protocols, which were mentioned previously. For enumerations, see Chapter 22 .