1
00:00:00,000 --> 00:00:07,566
[No audio]

2
00:00:07,567 --> 00:00:09,652
Welcome back again in the course.

3
00:00:09,653 --> 00:00:12,538
In this tutorial we will move ahead with the topic

4
00:00:12,539 --> 00:00:15,770
of variables and we'll cover some additional basic topics.

5
00:00:15,771 --> 00:00:17,252
So let's start.

6
00:00:17,253 --> 00:00:18,868
We will first look at how to

7
00:00:18,869 --> 00:00:22,058
initialize multiple variables in a single statement.

8
00:00:22,059 --> 00:00:24,228
To declare more than one variable of the

9
00:00:24,229 --> 00:00:26,618
same or different types, we use a comma

10
00:00:26,619 --> 00:00:29,674
separated list which is enclosed in smooth brackets.

11
00:00:29,675 --> 00:00:32,107
For instance, I will declare two variables with

12
00:00:32,108 --> 00:00:35,785
the name of first_number and second_number,

13
00:00:35,786 --> 00:00:38,204
and we'll set their values accordingly.

14
00:00:38,205 --> 00:00:42,280
[No audio]

15
00:00:42,281 --> 00:00:44,398
The two numbers have different types and

16
00:00:44,399 --> 00:00:48,340
the compiler has successfully inferred their types.

17
00:00:48,341 --> 00:00:52,772
We can always include more variables inside the smooth

18
00:00:52,773 --> 00:00:55,940
brackets if we wish to initialize more variables.

19
00:00:55,941 --> 00:00:57,902
Sometimes we may be dealing with

20
00:00:57,903 --> 00:01:00,210
very large numbers inside our program.

21
00:01:00,211 --> 00:01:02,408
To make the large numbers more readable,

22
00:01:02,409 --> 00:01:05,063
the Rust allows the uses of underscores.

23
00:01:05,064 --> 00:01:08,722
For instance, I will declare a variable large_number

24
00:01:08,723 --> 00:01:11,410
and we'll set its value to that of 1 million.

25
00:01:11,411 --> 00:01:15,320
[No audio]

26
00:01:15,321 --> 00:01:17,482
For better readability of the number, I

27
00:01:17,483 --> 00:01:20,180
can add underscores at the appropriate places.

28
00:01:20,181 --> 00:01:23,160
[No audio]

29
00:01:23,161 --> 00:01:26,692
Sometimes you may mistakenly assign a value to a variable

30
00:01:26,693 --> 00:01:29,502
of a certain type which may exceed the range of

31
00:01:29,503 --> 00:01:32,430
values that particular type of variable may hold.

32
00:01:32,431 --> 00:01:35,028
This is called integer overflow.

33
00:01:35,029 --> 00:01:38,286
For instance, if I declare a variable number of type

34
00:01:38,287 --> 00:01:41,842
u8, to that of a value of 256, you

35
00:01:41,843 --> 00:01:45,176
may note that I got a compile time error.

36
00:01:45,177 --> 00:01:47,586
This is because the upper limit for the u8

37
00:01:47,587 --> 00:01:51,220
is 255, and I am trying to exceed this limit.

38
00:01:51,221 --> 00:01:53,900
Please note that in some older versions of Rust,

39
00:01:53,901 --> 00:01:56,876
the compiler may not complain, but when you execute

40
00:01:56,877 --> 00:01:58,690
it will give you a wrong answer.

41
00:01:59,300 --> 00:02:03,308
Rust also has very easy mechanism to display the decimal

42
00:02:03,309 --> 00:02:06,768
number in other bases such as octal, binary and hexa.

43
00:02:06,769 --> 00:02:09,930
Suppose we have a variable x equals to 255.

44
00:02:09,931 --> 00:02:12,416
I will display the value of this variable

45
00:02:12,417 --> 00:02:15,582
in different formats inside the print statement by

46
00:02:15,583 --> 00:02:18,760
placing special syntax inside the placeholders.

47
00:02:18,761 --> 00:02:25,730
[No audio]

48
00:02:25,731 --> 00:02:28,388
To display the same variable in octal I will

49
00:02:28,389 --> 00:02:31,944
mention colon o inside the placeholder, and for the

50
00:02:31,945 --> 00:02:35,860
hexadecimal I will write colon followed by capital X,

51
00:02:35,861 --> 00:02:39,700
and for the binary colon b.

52
00:02:39,701 --> 00:02:42,390
[No audio]

53
00:02:42,391 --> 00:02:45,000
Let us run to see the output of this program.

54
00:02:45,001 --> 00:02:48,090
[No audio]

55
00:02:48,091 --> 00:02:50,274
Okay, a couple of more points regarding

56
00:02:50,275 --> 00:02:52,434
the variables which are quite handy.

57
00:02:52,435 --> 00:02:54,396
The Rust assume a snake case

58
00:02:54,397 --> 00:02:56,562
convention for the variable names.

59
00:02:56,563 --> 00:02:59,862
The snake case refers to the style of writing variable

60
00:02:59,863 --> 00:03:02,752
names in which first letter of the variables are in

61
00:03:02,753 --> 00:03:07,014
lowercase and each space is replaced with an underscore.

62
00:03:07,015 --> 00:03:10,176
For instance, if I write let Number equals to 45,

63
00:03:10,177 --> 00:03:12,868
you may note that there is an underline beneath the

64
00:03:12,869 --> 00:03:15,540
name of the variable which indicates to me that something

65
00:03:15,541 --> 00:03:18,810
needs our attention and needs to be fixed.

66
00:03:18,811 --> 00:03:21,652
Please note that a red line means an error, while

67
00:03:21,653 --> 00:03:24,610
an underline of this color is not an error.

68
00:03:24,611 --> 00:03:26,790
[No audio]

69
00:03:26,791 --> 00:03:29,038
Let us see the message of compiler

70
00:03:29,039 --> 00:03:31,438
in this case. Alongside other details,

71
00:03:31,439 --> 00:03:34,180
it says the variable name should be snake case.

72
00:03:34,710 --> 00:03:36,546
The program will, however compile

73
00:03:36,547 --> 00:03:38,034
and will not complain.

74
00:03:38,035 --> 00:03:41,292
The Rust, however, will keep on giving us this

75
00:03:41,293 --> 00:03:43,628
message as the Rust wants you to follow the

76
00:03:43,629 --> 00:03:46,950
convention of using snake case for variable names.

77
00:03:47,870 --> 00:03:49,904
If we look at the same message again,

78
00:03:49,905 --> 00:03:54,262
it also warned us about use unused variables.

79
00:03:54,263 --> 00:03:57,008
The compiler basically wants us to use all the

80
00:03:57,009 --> 00:03:59,740
variables that are being declared inside a program.

81
00:04:00,350 --> 00:04:02,708
It makes sense because if we do not use a

82
00:04:02,709 --> 00:04:05,492
variable, then it should not be part of the program.

83
00:04:05,493 --> 00:04:07,978
This is something nice about Rust because it helps

84
00:04:07,979 --> 00:04:11,130
in making sure that we write correct programs.

85
00:04:11,131 --> 00:04:13,816
Whenever you declare some variable and you do not

86
00:04:13,817 --> 00:04:16,712
use it inside the program, then as part of

87
00:04:16,713 --> 00:04:19,591
Rust safety feature, it will keep on reminding you

88
00:04:19,592 --> 00:04:22,019
that you have a variable which is not used.

89
00:04:23,030 --> 00:04:25,288
In the previous tutorial, we pointed out that

90
00:04:25,289 --> 00:04:26,988
you may not be able to perform the

91
00:04:26,989 --> 00:04:29,474
operations on variables of different types.

92
00:04:29,475 --> 00:04:31,468
For instance, an addition operation on

93
00:04:31,469 --> 00:04:34,250
variables of type, integer and float.

94
00:04:34,251 --> 00:04:36,236
We pointed out that there is

95
00:04:36,237 --> 00:04:38,204
a way for making this possible.

96
00:04:38,205 --> 00:04:41,638
To see this, I will declare a couple of variables.

97
00:04:41,639 --> 00:04:44,432
The first variable is n1 with a value of

98
00:04:44,433 --> 00:04:47,808
14, which means that it is an integer variable and

99
00:04:47,809 --> 00:04:53,418
the second variable n2 with a value of 15.6, means that it is a float variable.

100
00:04:53,419 --> 00:04:56,110
I will next try to add these two variables.

101
00:04:56,111 --> 00:04:59,390
[No audio]

102
00:04:59,391 --> 00:05:02,902
As expected, it will give me a compile time error.

103
00:05:02,903 --> 00:05:04,996
One of the reason for this error is that,

104
00:05:04,997 --> 00:05:07,940
as mentioned in the previous tutorial, the Rust is

105
00:05:07,941 --> 00:05:11,668
statically typed language, which means that it must know

106
00:05:11,669 --> 00:05:14,388
the types of all the variables at compile time.

107
00:05:14,389 --> 00:05:17,448
However, in this case it may not be able to infer the

108
00:05:17,449 --> 00:05:21,220
type of n3 because it is confused about its type.

109
00:05:22,150 --> 00:05:24,312
To clear this confusion, we may either

110
00:05:24,313 --> 00:05:26,302
convert the variable n1 to float

111
00:05:26,303 --> 00:05:29,410
or consider changing n2 to integer.

112
00:05:30,070 --> 00:05:31,996
Both the options are available

113
00:05:31,997 --> 00:05:33,644
and we will explore both.

114
00:05:33,645 --> 00:05:36,028
So let me first change the variable n2 to

115
00:05:36,029 --> 00:05:39,356
a type that matches the type of variable n1.

116
00:05:39,357 --> 00:05:42,892
This is done by writing n2 as i32, which

117
00:05:42,893 --> 00:05:46,086
will convert the variable n2 to n i32 variable

118
00:05:46,087 --> 00:05:48,780
during the computation of the value of n3.

119
00:05:49,470 --> 00:05:52,550
Please note that the variable n2 will not be permanently

120
00:05:52,551 --> 00:05:56,148
changed to an i32 type and it will just be

121
00:05:56,149 --> 00:05:59,812
treated as ani32 variable within this command and will

122
00:05:59,813 --> 00:06:04,218
return its type of f64 outside this command.

123
00:06:04,219 --> 00:06:06,930
Let us display the answer of the computation.

124
00:06:06,931 --> 00:06:12,420
[No audio]

125
00:06:12,421 --> 00:06:14,518
You may have noticed something here.

126
00:06:14,519 --> 00:06:17,078
The variable of n2 was having a value of

127
00:06:17,079 --> 00:06:20,518
15.6 and when we changed it to an integer, so

128
00:06:20,519 --> 00:06:23,478
its value has been changed to a value of 15.

129
00:06:23,479 --> 00:06:26,618
Therefore, the final answer is that of 29 instead of

130
00:06:26,619 --> 00:06:30,202
29.6, because the result of two integers will lead to

131
00:06:30,203 --> 00:06:33,130
an integer value and not a float value.

132
00:06:33,131 --> 00:06:36,522
So in this case we have some loss of value.

133
00:06:36,523 --> 00:06:38,718
The takehome message is that we need to

134
00:06:38,719 --> 00:06:40,606
be careful when we are changing the type

135
00:06:40,607 --> 00:06:42,810
of a variable from one type to another.

136
00:06:43,340 --> 00:06:44,830
To get the correct value,

137
00:06:44,831 --> 00:06:46,718
we should better change the value of type

138
00:06:46,719 --> 00:06:49,138
of n1 to that of float instead.

139
00:06:49,139 --> 00:06:52,194
So I will change n1 to f64 instead.

140
00:06:52,195 --> 00:06:53,870
Let us execute again.

141
00:06:53,871 --> 00:06:58,770
[No audio]

142
00:06:58,771 --> 00:07:00,880
This time we have the correct value.

143
00:07:02,130 --> 00:07:03,758
Now we will move to the next topic

144
00:07:03,759 --> 00:07:06,550
of the lecture, which is regarding shadowing.

145
00:07:06,551 --> 00:07:09,438
Shadowing in simple words refers to the concept

146
00:07:09,439 --> 00:07:12,142
of using or updating or declaring a variable

147
00:07:12,143 --> 00:07:14,462
with the same name which has been previously

148
00:07:14,463 --> 00:07:16,890
used or declared in the program.

149
00:07:16,891 --> 00:07:19,948
In the Rust community and literature, we say that the

150
00:07:19,949 --> 00:07:23,884
first variable is being shadowed by the second, which means

151
00:07:23,885 --> 00:07:27,602
that the second variable value is what the program sees

152
00:07:27,603 --> 00:07:30,140
when the variable is used inside the program.

153
00:07:30,670 --> 00:07:32,928
Let us now see the different cases in which

154
00:07:32,929 --> 00:07:35,260
the shadowing of a variable may take place.

155
00:07:35,870 --> 00:07:38,448
The first case is when we shadow a variable by

156
00:07:38,449 --> 00:07:42,394
using the same variable name and using the let keyword.

157
00:07:42,395 --> 00:07:45,440
I will declare a variable s with a value of 5.

158
00:07:46,530 --> 00:07:48,932
In the next line I will declare it again by

159
00:07:48,933 --> 00:07:52,000
assigning it a different value such as 5 times 5.

160
00:07:53,570 --> 00:07:56,664
The Rust will use the most recent or latest value

161
00:07:56,665 --> 00:07:59,736
which shadows the previous value of the variable s.

162
00:07:59,737 --> 00:08:01,806
In this case, the value of the variable

163
00:08:01,807 --> 00:08:05,290
s after executing the program will be 25.

164
00:08:05,291 --> 00:08:07,282
To confirm this, I will add a suitable

165
00:08:07,283 --> 00:08:09,960
print statement and execute to confirm the result.

166
00:08:09,961 --> 00:08:18,460
[No audio]

167
00:08:18,461 --> 00:08:20,388
The second case is when we shadow

168
00:08:20,389 --> 00:08:23,780
a mutable variable by an immutable variable.

169
00:08:23,781 --> 00:08:27,006
For instance, I will declare mutable variable p

170
00:08:27,007 --> 00:08:29,550
and make it equal to a value of 5.

171
00:08:29,551 --> 00:08:32,000
[No audio]

172
00:08:32,001 --> 00:08:34,562
In the next line I will make it immutable and

173
00:08:34,563 --> 00:08:37,789
will assign it a value of 5 times 5.

174
00:08:39,440 --> 00:08:41,926
This means that the mutable variable p

175
00:08:41,927 --> 00:08:44,732
is being shadowed by its immutable version.

176
00:08:44,733 --> 00:08:47,318
And now in the next line, if I try to update its

177
00:08:47,319 --> 00:08:50,778
value by assigning it a value of, let's say 60, so the

178
00:08:50,779 --> 00:08:53,540
compiler will complain and it will give us an error.

179
00:08:54,600 --> 00:08:56,842
The third case of shadowing occurs when

180
00:08:56,843 --> 00:08:58,560
we change the type of a variable.

181
00:08:58,561 --> 00:09:01,662
For instance, I will define a variable q as

182
00:09:01,663 --> 00:09:04,490
an integer by assigning it a value of 32.

183
00:09:06,140 --> 00:09:08,478
In the next line I will change its type to

184
00:09:08,479 --> 00:09:11,370
that of character by assigning it a value of a.

185
00:09:11,371 --> 00:09:13,420
[No audio]

186
00:09:13,421 --> 00:09:15,698
This will shadow its previous type.

187
00:09:15,699 --> 00:09:17,746
We can go ahead and shadow its

188
00:09:17,747 --> 00:09:20,018
type as many times as we like.

189
00:09:20,019 --> 00:09:21,608
The final case of shadowing

190
00:09:21,609 --> 00:09:23,704
occurs inside the code segments.

191
00:09:23,705 --> 00:09:25,602
Code segments are introduced inside

192
00:09:25,603 --> 00:09:27,544
the Rust using curly brackets.

193
00:09:27,545 --> 00:09:30,038
Any code inside the same curly brackets are

194
00:09:30,039 --> 00:09:32,428
said to be defined in the same scope.

195
00:09:32,429 --> 00:09:35,756
To explain how shadowing works inside the code segments,

196
00:09:35,757 --> 00:09:38,682
I will first declare a mutable variable r, and

197
00:09:38,683 --> 00:09:41,270
will initialize it from a value of 65.

198
00:09:41,271 --> 00:09:44,440
[No audio]

199
00:09:44,441 --> 00:09:45,962
Next, I will introduce a code

200
00:09:45,963 --> 00:09:48,020
segment by adding two curly brackets.

201
00:09:48,920 --> 00:09:52,206
Inside these brackets, I will declare a variable r

202
00:09:52,207 --> 00:09:55,530
again and will assign it a value of 60.

203
00:09:56,060 --> 00:09:58,692
I will also display the value of the variable

204
00:09:58,693 --> 00:10:01,480
inside the code segment using a print statement.

205
00:10:01,481 --> 00:10:06,730
[No audio]

206
00:10:06,731 --> 00:10:08,668
Now, outside the code segment, I will

207
00:10:08,669 --> 00:10:10,730
again display the value of the variable.

208
00:10:10,731 --> 00:10:15,500
[No audio]

209
00:10:15,501 --> 00:10:17,118
Now, let us explain what will

210
00:10:17,119 --> 00:10:18,750
be the output of this program.

211
00:10:18,751 --> 00:10:21,332
First, we should note that every variable in Rust

212
00:10:21,333 --> 00:10:24,244
has an associated scope in which it is known

213
00:10:24,245 --> 00:10:27,656
and its value is valid within that scope.

214
00:10:27,657 --> 00:10:30,696
Outside the scope, the variable will not be known.

215
00:10:30,697 --> 00:10:33,378
The variables defined inside a code segment has a

216
00:10:33,379 --> 00:10:36,908
scope that is limited to that particular code segment.

217
00:10:36,909 --> 00:10:39,382
Variables not in any code segment has

218
00:10:39,383 --> 00:10:41,700
scope equal to the main function.

219
00:10:41,701 --> 00:10:43,798
We will explain the concept of scope in

220
00:10:43,799 --> 00:10:46,580
more detail when we cover the lifetimes.

221
00:10:46,581 --> 00:10:48,950
Now, once we understand this, now,

222
00:10:48,951 --> 00:10:50,362
let us look at the code.

223
00:10:50,363 --> 00:10:52,746
First, we define a variable r, which

224
00:10:52,747 --> 00:10:55,450
will have a value of 65.

225
00:10:55,451 --> 00:10:57,962
Inside the code segment, we declare variable r

226
00:10:57,963 --> 00:11:00,522
again with the let keyword having a value

227
00:11:00,523 --> 00:11:03,694
of 60, which shadows its previous value.

228
00:11:03,695 --> 00:11:06,932
Since this variable r is residing inside the code segment,

229
00:11:06,933 --> 00:11:10,932
therefore, its value will only be retained within the boundaries

230
00:11:10,933 --> 00:11:13,880
of this code segment, which is its scope.

231
00:11:14,780 --> 00:11:16,808
In other words, the effect of shadowing

232
00:11:16,809 --> 00:11:18,562
will be limited to this particular code

233
00:11:18,563 --> 00:11:21,360
segment and will not be reflected outside.

234
00:11:21,361 --> 00:11:23,458
When the scope ends, the value of the

235
00:11:23,459 --> 00:11:26,072
variable r would return back to its original

236
00:11:26,073 --> 00:11:28,850
value and the original value which is 65.

237
00:11:29,620 --> 00:11:31,686
The point to note is that when a value

238
00:11:31,687 --> 00:11:34,294
is being shadowed with the let keyword in a

239
00:11:34,295 --> 00:11:37,542
scope, it only remains in that scope and will

240
00:11:37,543 --> 00:11:40,362
return to its value once the scope is over.

241
00:11:40,363 --> 00:11:42,394
Let us execute to confirm the value of

242
00:11:42,395 --> 00:11:45,300
the variable inside and outside the code segments.

243
00:11:45,301 --> 00:11:52,000
[No audio]

244
00:11:52,001 --> 00:11:54,258
If we, however remove the let keyword from

245
00:11:54,259 --> 00:11:57,142
the variable r inside the code segment, then

246
00:11:57,143 --> 00:12:00,260
the value of r will be permanently changed.

247
00:12:00,261 --> 00:12:02,690
Let us change the value and execute again.

248
00:12:02,691 --> 00:12:07,370
[No audio]

249
00:12:07,371 --> 00:12:09,996
We may note that inside and outside the code

250
00:12:09,997 --> 00:12:12,976
segment, the value of the variable is the same.

251
00:12:12,977 --> 00:12:14,400
Let us now move to the final

252
00:12:14,401 --> 00:12:17,094
topic and that is related to constants.

253
00:12:17,095 --> 00:12:20,918
The very first question is, what are constants?

254
00:12:20,919 --> 00:12:23,972
The constants are data values that remains the same and

255
00:12:23,973 --> 00:12:27,410
are not changed every time a program is executed.

256
00:12:27,411 --> 00:12:30,218
Typical examples of constants include mathematical

257
00:12:30,219 --> 00:12:32,548
constants and configuration values that the

258
00:12:32,549 --> 00:12:34,762
program uses. Like variables,

259
00:12:34,763 --> 00:12:37,784
they also have an associated name.

260
00:12:37,785 --> 00:12:40,152
You may be wondering that we

261
00:12:40,153 --> 00:12:42,936
have the immutable variables also, right?

262
00:12:42,937 --> 00:12:45,016
So they have names and do not change.

263
00:12:45,017 --> 00:12:46,440
So what is the essential difference

264
00:12:46,441 --> 00:12:49,610
between an immutable variable and constant?

265
00:12:49,611 --> 00:12:52,194
The first difference is that you are not allowed

266
00:12:52,195 --> 00:12:55,282
to use the keyword of mut with constants.

267
00:12:55,283 --> 00:12:57,228
Constants are always immutable and

268
00:12:57,229 --> 00:12:59,450
cannot be changed to mutable.

269
00:12:59,451 --> 00:13:02,416
Secondly, you will declare constants using the const

270
00:13:02,417 --> 00:13:04,928
keyword instead of the let keyword, and the

271
00:13:04,929 --> 00:13:07,206
type of the value must be annotated.

272
00:13:07,207 --> 00:13:10,512
The compiler will not infer and add the type for you.

273
00:13:10,513 --> 00:13:14,130
It's your responsibility to add the type to it.

274
00:13:14,131 --> 00:13:17,316
Rust's naming convention for constants is to use

275
00:13:17,317 --> 00:13:21,600
all uppercase with underscore between words.

276
00:13:22,290 --> 00:13:24,132
Let us declare a constant called

277
00:13:24,133 --> 00:13:26,180
MAX_SALARY to some value.

278
00:13:26,181 --> 00:13:30,320
[No audio]

279
00:13:30,321 --> 00:13:32,738
As pointed out earlier, the underscore is

280
00:13:32,739 --> 00:13:34,620
used for the sake of readability.

281
00:13:36,560 --> 00:13:39,160
Okay, that brings us to the end of this tutorial.

282
00:13:39,161 --> 00:13:41,858
We have covered some important concepts that are

283
00:13:41,859 --> 00:13:44,600
necessary to give us a quick start.

284
00:13:44,601 --> 00:13:47,078
You may be noticing that we are covering things at

285
00:13:47,079 --> 00:13:49,862
a very slow pace and in quite some detail.

286
00:13:49,863 --> 00:13:52,908
This is because we want to take everyone abroad,

287
00:13:52,909 --> 00:13:55,606
including those who have some Rust knowledge and also

288
00:13:55,607 --> 00:13:57,932
those who are new to Rust programming.

289
00:13:57,933 --> 00:14:00,246
Once we have built sufficient skills and strong

290
00:14:00,247 --> 00:14:03,004
foundations, then we will be covering the material

291
00:14:03,005 --> 00:14:04,798
at a bit faster pace and there will

292
00:14:04,799 --> 00:14:07,534
be more knowledge covered in lesser time.

293
00:14:07,535 --> 00:14:09,278
In the upcoming tutorial we will be

294
00:14:09,279 --> 00:14:11,876
covering more about the compound data types.

295
00:14:11,877 --> 00:14:16,440
Do come back for covering that,  and until next tutorial, happy Rust programming.

296
00:14:16,441 --> 00:14:21,666
[No audio]