1
00:00:00,350 --> 00:00:02,430
We saw that it's possible to declare and

2
00:00:02,430 --> 00:00:04,460
unwrap the optionals
with the question mark.

3
00:00:04,460 --> 00:00:09,670
Now we'll see that it's possible to do
both the exclamation point as well.

4
00:00:09,670 --> 00:00:12,270
Let's look at unwrapping first.

5
00:00:12,270 --> 00:00:15,200
If we have a variable named x,
we can unwrap it like this.

6
00:00:15,200 --> 00:00:18,910
The exclamation point follows the
variable just like the question mark.

7
00:00:18,910 --> 00:00:22,052
But if the value inside is nil,
it explodes.

8
00:00:22,052 --> 00:00:24,800
All right, nothing explodes,
but it does throw an exception.

9
00:00:24,800 --> 00:00:27,950
There's no safe way to unwrap an if
statement with an exclamation point.

10
00:00:27,950 --> 00:00:31,380
You can think of this as failing fast.

11
00:00:31,380 --> 00:00:34,230
When you choose to unwrap with
an exclamation point, you're saying that

12
00:00:34,230 --> 00:00:38,150
you want the program to crash if
the variable contains a nil value.

13
00:00:38,150 --> 00:00:40,980
It communicates to your code readers
that you are fully confident that there

14
00:00:40,980 --> 00:00:43,540
will not be a nil value in the optional.

15
00:00:43,540 --> 00:00:47,160
We can use the exclamation point
to declare an optional too.

16
00:00:47,160 --> 00:00:49,530
We follow the data type
with an exclamation point,

17
00:00:49,530 --> 00:00:51,160
right where the question
mark went before.

18
00:00:52,410 --> 00:00:54,420
But this will be a special
kind of optional,

19
00:00:54,420 --> 00:00:56,990
an implicitly unwrapped optional.

20
00:00:56,990 --> 00:00:59,820
That means that any time the optional
is used in an expression,

21
00:00:59,820 --> 00:01:01,360
it will be automatically unwrapped.

22
00:01:02,640 --> 00:01:05,970
It is an optional, so
it can store a value or nil.

23
00:01:05,970 --> 00:01:09,600
You might think of it as a very fragile
package that automatically falls open or

24
00:01:09,600 --> 00:01:11,500
unwraps whenever it's picked up.

25
00:01:11,500 --> 00:01:13,560
Here too there's an explosive quality.

26
00:01:13,560 --> 00:01:16,000
If we don't unwrap it carefully,

27
00:01:16,000 --> 00:01:20,280
it's automatically unwrapped any
time it's used in an expression.

28
00:01:20,280 --> 00:01:23,710
If automatically unwraps and it contains
a nil, then an exception will be thrown.

29
00:01:24,790 --> 00:01:27,160
How can we use these
dangerous types of optionals?

30
00:01:27,160 --> 00:01:29,360
Let's look at some quick examples.

31
00:01:29,360 --> 00:01:32,620
Essentially you only use the exclamation
point when you're sure that the optional

32
00:01:32,620 --> 00:01:33,710
won't have a nil.

33
00:01:33,710 --> 00:01:36,990
An invocation of toInt is always
going to return an optional.

34
00:01:36,990 --> 00:01:40,550
But in this case there's not a lot of
doubt about what that optional holds.

35
00:01:40,550 --> 00:01:45,580
If an optional is like a package, this
package is going to have 123 inside it.

36
00:01:45,580 --> 00:01:47,570
We can unwrap it boldly.

37
00:01:47,570 --> 00:01:50,530
We could of unwrapped the optional
right as it returned.

38
00:01:50,530 --> 00:01:54,466
In that case, x would have been created
as an int instead of an int optional,

39
00:01:54,466 --> 00:01:56,540
and it won't need to be unwrapped.

40
00:01:56,540 --> 00:01:59,910
This is a nice example of how swift
infers the type of variables when we

41
00:01:59,910 --> 00:02:01,330
initialize them.

42
00:02:01,330 --> 00:02:05,400
By unwrapping this optional return
type right when it is returned,

43
00:02:05,400 --> 00:02:08,240
we make it not an int optional but
a plain old int.

44
00:02:08,240 --> 00:02:10,550
And so x is declared as a plain old int.

45
00:02:10,550 --> 00:02:14,310
How about declaring an optional
with an exclamation point?

46
00:02:14,310 --> 00:02:18,260
I referred to that earlier as
the implicitly unwrapped optional.

47
00:02:18,260 --> 00:02:20,340
When we use view controllers
with storyboard,

48
00:02:20,340 --> 00:02:23,550
we need properties that can be nil
when the object is first created.

49
00:02:23,550 --> 00:02:26,600
But we can also be confident that
the values will get set by storyboard.

50
00:02:26,600 --> 00:02:30,220
You will remember that this button needs
to be an optional, but we can declare it

51
00:02:30,220 --> 00:02:33,860
as an implicitly unwrapped optional
with an exclamation point.

52
00:02:33,860 --> 00:02:36,560
From now on this button property
can be used without unwrapping it.

53
00:02:37,630 --> 00:02:41,300
Anytime it is used in an expression
it will be automatically unwrapped.

54
00:02:41,300 --> 00:02:43,260
It has a slightly reckless feel.

55
00:02:43,260 --> 00:02:46,890
If the button is storing nil when it is
unwrapped, it will cause an exception.

56
00:02:46,890 --> 00:02:49,980
Here we recklessly use the button and
pay the price.

57
00:02:49,980 --> 00:02:53,520
Because the button contained nil,
we get an EXEC_BAD_INSTRUCTION.

58
00:02:53,520 --> 00:02:55,610
The program really crashes.

59
00:02:55,610 --> 00:02:58,480
It can be a little bit hard to tell
why it crashed, since the error is

60
00:02:58,480 --> 00:03:03,150
up here on the very first line,
but this came from the unwrapping.

61
00:03:03,150 --> 00:03:06,430
In reality, we'd only use an implicitly
unwrapped optional when we have reason

62
00:03:06,430 --> 00:03:08,160
to know that the button will be there.

63
00:03:08,160 --> 00:03:11,530
Now that we've added the button back in,
the compiler's happy.

64
00:03:11,530 --> 00:03:15,500
Well, we hope that this jump starts
a new confidence for you with optionals.

65
00:03:15,500 --> 00:03:18,160
They're a bread and butter technique for
swift programmers, and

66
00:03:18,160 --> 00:03:19,960
it pays to really master them.

67
00:03:19,960 --> 00:03:22,020
Take some time to work through
the recommended reading and

68
00:03:22,020 --> 00:03:25,880
a few exercises before you go
back to IB action and IB outlets