In

What we’ve been doing with the question mark operator is exactly what this chapter is all about. It’s called unwrapping. As you can imagine it is the concept of removing the wrapping around an optional. As an analogy just think of little you sitting underneath the Christmas tree and removing the wrapping around your Christmas present. You don’t know what’s inside until you open up the wrapping and „surprise“ only then can you know for sure what’s inside. Often times we can guess what’s inside the present but to be certain, we have to remove the wrapping and take a look at the content.

Exactly the same is true for our optionals. We can make an educated guess about what’s inside the optional but to be certain, we have to unwrap it.

To be able to unwrap our optionals, we have to know the ways to unwrap. We’ve used the question mark so far, but now I’ll introduce you to force unwrapping. Also, we’re going to take a look at how we can make the unwrapping much more secure and elegant, because right now we don’t have a lot of information about wether an unwrap was successful or not. Lastly we’ll take a look at how to use scope variables to bypass multiple force unwraps and to look at some best practices when dealing with optionals because a lot can go wrong and you have to make sure your code runs smoothly.

Force Unwrapping

The force unwrapping operator is – as you can imagine – not a question mark but an exclamation mark. If you remember correctly we used the question mark all the time but we didn’t have much information about what was going on with our optional. We didn’t know if our function call was working and no other information in general. Our code would get executed if everything was alright, if not, we wouldn’t get any notice. Sometimes that’s what you want, and sometimes this can be really painful because it makes testing much more difficult.

Ugly Unwrapping

The force unwrap does work a little different. It basically forces the compiler to use the variable how you told him to. It’s like saying „Hey I need this variable here. Just remove the wrapping and do the work that I told you to. You can be certain that there’s something in there that can handle the function.“

As you can imagine this only works properly, if there is the expected object inside of the optional, if not your code will break into pieces and the app will crash.

Let’s just look at an example.

Demo in Xcode

To make this code more elegant, we’re going to make use of scope variables to make our code more secure. Our starting point would look somehting like this. We would have our guard statement and check if it’s not nil and the we could use the exclamation mark right here to scramble our eggs.

What I don’t like about this approach, is that we would have to write the exclamation mark at every single function call below our guard statement. But our guard checks if everything is alright with our optional, which is why I want to be able to code without force unwrapping the optional every single time I need it.

Save Unwrapping

What we can now do, is define a scope variable. It would look something like this. What we’ve done here is we created a new variable – let unwrappedEggs -of a certain type – Eggs – and the we use our optional to push it inside of this non optional variable. What this does is, it takes the eggs put it inside this non optional variable. If our optional eggs actually contains eggs, this will succeed and the unwrapped optional will be put into unwrappedEggs. Otherwise, if our eggs are nil, this statement will fail and we’d run into the else block of our guard where we could about because our eggs are non existent.

We can now use our unwrappedEggs scope variable without any explicit unwrapping because it is not an optional anymore and the code only get executed if the guard passes.

Let’s look at this in code and then I’ll explain what’s going on.

Demo in Xcode

To sum it up:

  1. We create a guard statement
  2. Inside we declare a new variable
  3. Unwrap the optional into the new non-optional variable
  4. If successful -> not nil
  5. if condition violated -> optional is nil

Now that’s a very handy way to deal with optionals because it makes sure you only need to deal with optionals in certain parts of your code, you don’t have to always be aware of the fact that something is an optional. Also this is helpful for debugging because you’ll know exactly where to look if your app crashes because of the optional. It can only be where the optional is unwrapped.

Another benefit of this is that you can use the unwrapping process while casting the optional into something different. This is very useful if you’re dealign with a set of subclasses and you don’t know exactly which object is inside the optional.

For example we could say that our eggs are of type food and then try to cast the food into eggs. If it works, we know that our food is of type eggs or if it fails it could be of type pumpkin or whatever. I won’t go into too much detail with the casting here because it would take much too long, but just know, that this is possible. It might save you a lot of time and make your code much more efficient and readable.

So that’s it for this lesson, now we get into chapter 6 which is our summary and then we’ll get to the assignment.

Ask Anything!

Do you have any questions? Ask them! I'll answer via Email as soon as I read it.

Not readable? Change text. captcha txt
0