So what use does an optional offer us?

Many languages don't have a feature to indicate that a type could be nil or

NULL at some point.

Instead, we have to remember to check in many places.

For example, let's take a look at some Objective-C code.

In Objective-C, like a lot of languages, anything can be set to nil.

This seems useful at first if you don't have a value for some type.

You can easily set it to nil.

But this means we have to constantly be checking if that something is nil.

Think of it this way.

We talked about constants and variables being boxes, right?

Imagine that when opening the box, if the value inside is nil and

we simply open the box, the box just explodes.

Think of a box exploding as equivalent to your app crashing.

>> [SOUND] >> Objective-C is kind of like that.

If you're not expecting nil and you open the box, you get an app crash.

That is, your box is going to explode.

>> [SOUND] [COUGH] >> As you saw from the code earlier,

let's put it back up on the screen,

there's nothing to indicate that this type could contain a nil value.

When it holds a string, the type is NSString.

And when it holds nil, the type is still NSString.

So the chances of our box exploding is pretty high.

Going back to our example,

let's say that we have a special box opener that diffuses this nil bomb.

If we open the box with this special opener and it's nil, we're okay.

We can continue working.

But using this special opener is cumbersome, and

we need to manually remember it, so

developers get lazy and forget to use it sometimes, and our boxes explode.

>> [SOUND] [COUGH] >> Swift,

on the other hand, indicates that a box can be nil.

And if the box is nil, you can only open it with this safe opener.

You could try to open it regularly, but it won't open it.

It forces you to use this safe option.

Here we have an instance of Person that I've created with my first and last name.

Let's add a method to the struct,

an instance method, that lets us return a person's full name.

So we'll call this method fullName, and it returns a String.

Inside, we can just concatenate the three properties to form a fullName

string and return it.

So we'll say return firstName + " "

+ middleName + " " + lastName.

Now, the second we do this, we get a compiler error.

Swift won't let us do this, and this is because middleName

right here is an optional string and it may not contain a value.

We can't concatenate a string that could possibly not be a string, right?

How do you add nil to this string right here?

This highlights an important point.

A string and an optional string are not the same type.

The optional string can be nil, but a regular string cannot.

In a language without the type safety, an optional feature that Swift has,

this code would work fine.

It would compile perfectly.

But if I called it on my name, it would explode, it would crash.

To work with the value, we need to unwrap it.

If you think of an optional as this special protection around a potentially

nil value, unwrapping means peeling that layer of protection and

using the value inside if it exists.

There are several ways we can unwrap an optional.

And for all these different ways, control flow is our friend.

So let's go back in here, and we'll get rid of this.

We'll start with a simple if statement and check if middleName is equal to nil.

So we'll say if middleName == nil.

Then we're only going to return the first and last name.

So return firstName + " " + lastName.

Now, I know I can use string interpolation so that I don't have to concatenate

a string with whitespace, but there's a reason for that.

Now, if the middle name is not nil, we can return the full name.

So we'll return firstName + " "

+ middleName + " " + lastName.

Well, this doesn't work, obviously,

because middleName is still wrapped inside this optional box.

We need to get that value out.

So again, we're going to add one character after middleName, with no spaces,

add an exclamation point.

And just like that, it works.

This actually compiles.

So now, if I type me.fullName, and we call the instance method,

I should get my full name back without a middle name, as you can see right here.

If I were to add some random middle name in here, that'll also work.

So this is the first way that you can unwrap a value

using this exclamation point.

But now that I've shown you this,

I want you to immediately erase it from your mind forever.

Never ever, ever, ever do this.

Using an exclamation mark like this is called force unwrapping.

What this indicates is I know that this is an optional, and

I know that this definitely has a value, so go ahead and rip it out and use it.

This is bad code.

Now, in this case it's code that works, but you're not guaranteed.

Here's why.

In a general case, if this middle name value happens to be nil and

you forget to write this if else check for a nil value, then your code will crash.

To make this work,

you have to write the nil check first using an if-else statement.

And it's really easy to forget or

ignore it because it works in the few situations that you've imagined.

It's so much easier to write just one character than all of this.

Now, as we learn more, there are going to be places where using this exclamation

point is simply unavoidable.

But those places are very few.

Honestly, when I see students' code samples,

if it contains an exclamation point, I consider myself having failed at my job.

This is really something you need to avoid until you know more about

when it's useful.

Now that you know how absolutely not to do things, let's look at the right way.

Most of you will think the right way involves writing more code,

but that's okay.

The job of a programmer isn't to write fast code with as few words as possible,

it's to write safe code.

With that, let's move on.