- Building Blocks of Swift
- Merging Variables into a String
- Optionals: A Gift to Unwrap
- Tuples
- Number Types
- From Objective-C to Swift
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Optionals: A Gift to Unwrap
In our tour through the basic building blocks of Swift, we come to optionals. Optionals are a unique feature of Swift, and they are used quite extensively. Optionals allow you to safely run code where a value may missing, which would normally cause errors. Optionals take some getting used to. Optionals help you achieve clean-looking code with fewer lines while also being stricter.
In many languages, you need to check objects to see whether they are nil or null. Usually, you write some pseudo-code that looks like the following. In this example we check for not null in JavaScript:
if(something != null) {...
In Swift, an optional either contains a value or it doesn’t. In other languages, we often have to deal with missing values, such as a variable that once contained a value but no longer does. Or when a variable is initialized without a value. To mark something as optional, you just include a ? next to the type of the object. For example, here’s how you create a String optional:
var someString:String? = "Hey there!"
You can now say that someString is of type String? (a “String optional”) and no longer just of type String. Try printing that variable as an optional string and then as a regular string. Notice the difference in their returned values.
var greetingOptional:String? = "hi there"
var greeting:String = "Hi"
print(greetingOptional) //Optional("hi there")
print(greeting) //"Hi"
If you choose to use an optional and it does contain a value, you must do something special to get raw value out. Optionals must be “unwrapped” in order to get their value back. There are a couple ways to get the value out of an optional. When you see a variable of type String?, you can say that this variable may or may not contain a value. You will test this String optional to find out whether it does in fact have a value. How do you test an optional? There are a couple of ways. First try to use value binding.
Value binding allows you to do two things. First, it allows you to test the optional to see whether it is nil (whether it contains a value). Second, if that variable is not nil, value binding allows you to grab the value out of the optional and have it passed into a constant as a locally scoped variable. To see this in action, take a look at an example, but before you can try it out, you first need to open a new playground:
- Open Xcode.
- Click Get started with a playground.
- Save a new playground file by giving it a filename.
Now you can try out value binding with optionals:
var hasSomething:String? = "Hey there!"
if let message = hasSomething {
"Message was legit: \(message)"
} else {
"There was no message!"
}
A couple of new things are going on here. Let’s go through this example one step at a time:
- On the first line, you create a variable as usual, but you add the ? to say that this is a String optional. This means that this String may contain a value or nil. In this case, it contains a value. That value is the string "Hey there!".
- Next, you write an if statement. You are testing whether the variable hasSomething is nil. At the same time, you are assigning that value of the optional to a constant message. If the variable contains a value, you get a new constant (available only in the local scope, so we call it a locally scoped constant), which is populated with the raw value of the optional. You will then enter into the if statement body.
- If you do enter into that if statement, you now have a message to use. This constant will be available only in that if statement.
However, sometimes you are absolutely sure that your optional contains a value and is not empty. You can think of optionals as a gift that needs to be unwrapped. If an optional is nil inside, it will not throw an error when you use it. In other languages, trying to access something of nil (or null) value throws an error.
You can unwrap an optional by using an exclamation point. That is, you can get the value inside the optional by using an exclamation point. Let’s look again at our earlier example:
var hasSomething:String? = "Hey there!"
print(hasSomething) // Optional("Hey there!")\n
// Now unwrap the optional with the "!"
print(hasSomething!) // "Hey there!\n"
If you were sure that the string contained a value, you could unwrap the optional with the “!.” Now you can get the value out of the optional with one extra character. Remember how we said optionals are like wrapped-up presents? Well, it’s sometimes good to think of them more like bombs in Minesweeper. If you are too young for Minesweeper, think of them as presents that could contain bombs. You want to unwrap an optional with the “!” only if you are absolutely sure it contains a value. You want to unwrap an optional with the “!” only if you are absolutely sure it does not contain nil. If you unwrap an optional that’s nil, using “!,” then you will throw a fatal error, and your program will crash:
var hasSomething:String? //declare the optional string with no initial value // Now try and force it open hasSomething! // fatal error: Execution was interrupted, reason: EXC_BAD_INSTRUCTION...
When you get an EXC_BAD_INSTRUCTION somewhere, it means that your app is trying to access something that does not exist, which could be an error with an empty optional trying to unwrap with the “!.”
Printing Your Results
When you use the playground to test your code, you have two options for printing data. You can simply just write it, like this:
var someString = "hi there" someString //prints "hi there" in the output area
You can also use print(), which prints to the console output area. When you are making a full-fledged app, compiling code outside a playground, you’ll want to use print(), like this, because just writing the variable will not do anything:
var someString = "hi there" print(someString) //prints "hi there" in the console output
Implicitly Unwrapped Optionals
Sometimes you want to create an optional that gets unwrapped automatically. To do this, you assign the type with an exclamation point instead of a question mark:
var hasSomething:String! = "Hey there"// implicitly unwrapped optional string hasSomething // print the implicitly unwrapped optional and get the unwrapped value.
You can think of implicitly unwrapped optionals as a present that unwraps itself. You should not use an implicitly unwrapped optional if a chance exists that it may contain nil at any point. You can still use implicitly unwrapped optionals in value binding to check their values.
So why should you create implicitly unwrapped optionals in the first place if they can be automatically unwrapped? How does that make them any better than regular variables? Why even use them in the first place? These are fantastic questions, and we will answer them later, after we talk about classes and structures in Chapter 4, “Structuring Code: Enums, Structs, and Classes.” One quick answer is that sometimes we want to say that something has no value initially but we promise that it will have a value later. Properties of classes must be given a value by the time initialization is complete. We can declare a property with the exclamation point to say, in effect, “Right now it does not have a value, but we promise we will give this property a value at some point.”
Also, sometimes you will have a constant that cannot be defined during initialization, and sometimes you will want to use an Objective-C API. For both of these reasons and more, you will find yourself using implicitly unwrapped optionals. The following example has two examples (with some concepts not covered yet) in which you would commonly use implicitly unwrapped optionals.
class SomeUIView:UIView {
@IBOutlet var someButton:UIButton!
var buttonWidth:CGFloat!
override func awakeFromNib() {
self.buttonOriginalWidth = self.button.frame.size.width
}
}
In this example you have a button, which you cannot initialize yourself because the button will be initialized by Interface Builder. Also, the width of the button is unknown at the time of the creation of the class property, so you must make it an implicitly unwrapped optional. You will know the width of the button after awakeFromNib runs, so you promise to update it then.