01-20 Ok but what about Exclamation Points

01-20 Ok but what about Exclamation Points

We saw that it's possible to declare and

unwrap the optionals
with the question mark.

Now we'll see that it's possible to do
both the exclamation point as well.

Let's look at unwrapping first.

If we have a variable named x,
we can unwrap it like this.

The exclamation point follows the
variable just like the question mark.

But if the value inside is nil,
it explodes.

All right, nothing explodes,
but it does throw an exception.

There's no safe way to unwrap an if
statement with an exclamation point.

You can think of this as failing fast.

When you choose to unwrap with
an exclamation point, you're saying that

you want the program to crash if
the variable contains a nil value.

It communicates to your code readers
that you are fully confident that there

will not be a nil value in the optional.

We can use the exclamation point
to declare an optional too.

We follow the data type
with an exclamation point,

right where the question
mark went before.

But this will be a special
kind of optional,

an implicitly unwrapped optional.

That means that any time the optional
is used in an expression,

it will be automatically unwrapped.

It is an optional, so
it can store a value or nil.

You might think of it as a very fragile
package that automatically falls open or

unwraps whenever it's picked up.

Here too there's an explosive quality.

If we don't unwrap it carefully,

it's automatically unwrapped any
time it's used in an expression.

If automatically unwraps and it contains
a nil, then an exception will be thrown.

How can we use these
dangerous types of optionals?

Let's look at some quick examples.

Essentially you only use the exclamation
point when you're sure that the optional

won't have a nil.

An invocation of toInt is always
going to return an optional.

But in this case there's not a lot of
doubt about what that optional holds.

If an optional is like a package, this
package is going to have 123 inside it.

We can unwrap it boldly.

We could of unwrapped the optional
right as it returned.

In that case, x would have been created
as an int instead of an int optional,

and it won't need to be unwrapped.

This is a nice example of how swift
infers the type of variables when we

initialize them.

By unwrapping this optional return
type right when it is returned,

we make it not an int optional but
a plain old int.

And so x is declared as a plain old int.

How about declaring an optional
with an exclamation point?

I referred to that earlier as
the implicitly unwrapped optional.

When we use view controllers
with storyboard,

we need properties that can be nil
when the object is first created.

But we can also be confident that
the values will get set by storyboard.

You will remember that this button needs
to be an optional, but we can declare it

as an implicitly unwrapped optional
with an exclamation point.

From now on this button property
can be used without unwrapping it.

Anytime it is used in an expression
it will be automatically unwrapped.

It has a slightly reckless feel.

If the button is storing nil when it is
unwrapped, it will cause an exception.

Here we recklessly use the button and
pay the price.

Because the button contained nil,
we get an EXEC_BAD_INSTRUCTION.

The program really crashes.

It can be a little bit hard to tell
why it crashed, since the error is

up here on the very first line,
but this came from the unwrapping.

In reality, we'd only use an implicitly
unwrapped optional when we have reason

to know that the button will be there.

Now that we've added the button back in,
the compiler's happy.

Well, we hope that this jump starts
a new confidence for you with optionals.

They're a bread and butter technique for
swift programmers, and

it pays to really master them.

Take some time to work through
the recommended reading and

a few exercises before you go
back to IB action and IB outlets