1 00:00:00,210 --> 00:00:05,340 In this lecture, we're going to explore an alternative feature to conditional statements. 2 00:00:05,610 --> 00:00:09,300 Rust has a syntax feature called Match Expressions. 3 00:00:09,630 --> 00:00:15,060 They allow us to perform a comparison against a series of patterns if there's a match. 4 00:00:15,180 --> 00:00:16,560 We can run some code. 5 00:00:16,920 --> 00:00:21,990 Theoretically, we can control the flow of an application with match expressions. 6 00:00:22,290 --> 00:00:28,860 After reviewing the syntax for match expressions, we'll discuss the differences between match expressions 7 00:00:28,860 --> 00:00:30,630 and conditional statements. 8 00:00:31,200 --> 00:00:32,250 Let's get started. 9 00:00:32,549 --> 00:00:37,230 At the moment, we're informing the user of their qualification for free shipping. 10 00:00:37,470 --> 00:00:39,990 However, we haven't updated the total. 11 00:00:40,290 --> 00:00:43,950 If the user has free shipping, their total will remain the same. 12 00:00:44,370 --> 00:00:50,460 On the other hand, if they don't qualify, the shipping price will need to be added on top of the total. 13 00:00:51,090 --> 00:00:57,120 Theoretically, we could update the total inside the IFF block for demonstration purposes. 14 00:00:57,240 --> 00:01:00,990 Let's learn how to perform this action with match expressions. 15 00:01:01,320 --> 00:01:02,520 First things first. 16 00:01:02,820 --> 00:01:07,320 The total variable will need to be immutable, as we learned previously. 17 00:01:07,500 --> 00:01:09,270 Variables are immutable. 18 00:01:09,600 --> 00:01:14,490 Updating the total will require the mute keyword on the total variable. 19 00:01:16,960 --> 00:01:24,790 Next, let's create a variable to store a Boolean value below the total value defined immutable variable 20 00:01:24,790 --> 00:01:28,300 called free shipping with an initial value of false. 21 00:01:30,860 --> 00:01:34,460 We're going to assume the user does not qualify for a free shipping. 22 00:01:34,790 --> 00:01:41,210 This variable should be updated inside the IFF block will toggle the value to true. 23 00:01:43,860 --> 00:01:50,610 The next step is to check this variable to calculate the final cost after the series of conditional 24 00:01:50,610 --> 00:01:51,300 statements. 25 00:01:51,480 --> 00:01:53,370 Let's add the match keyword. 26 00:01:56,040 --> 00:02:00,580 The match keyword performs a similar operation to a conditional statements. 27 00:02:01,010 --> 00:02:06,600 We can use match expressions to compare values after typing the match keyword. 28 00:02:06,870 --> 00:02:10,350 We need to provide a value to perform comparisons on. 29 00:02:10,680 --> 00:02:13,110 We'll add the free shipping variable. 30 00:02:13,350 --> 00:02:16,050 Next, we need to add curly braces. 31 00:02:18,700 --> 00:02:24,670 Inside the curly braces, we need to provide a list of values to compare against the variable. 32 00:02:25,090 --> 00:02:29,350 Unlike conditional statements, match expressions are exhaustive. 33 00:02:29,710 --> 00:02:32,950 This means we need to account for every possibility. 34 00:02:33,280 --> 00:02:36,340 In our example, our variable is a Boolean. 35 00:02:36,650 --> 00:02:39,340 Hooligans can have one of two values. 36 00:02:39,580 --> 00:02:41,350 They can be true or false. 37 00:02:41,950 --> 00:02:44,800 We are required to account for both scenarios. 38 00:02:45,070 --> 00:02:51,730 For example, inside the block, let's handle the scenario where the free shipping variable is true. 39 00:02:52,120 --> 00:02:55,960 Then, after the value, we can add a fat error. 40 00:02:58,750 --> 00:03:05,230 The code after this arrow is the code to execute if there's a match, we'll update the total property 41 00:03:05,260 --> 00:03:10,690 by adding zero, which essentially means they won't have to pay for free shipping. 42 00:03:13,320 --> 00:03:19,740 After adding this value, we're thrown in error, the error states we haven't covered a false value. 43 00:03:20,040 --> 00:03:23,610 Rust is very strict and demanding with match expressions. 44 00:03:23,850 --> 00:03:25,740 We can't permit a possibility. 45 00:03:26,040 --> 00:03:28,380 All possibilities must be handled. 46 00:03:28,740 --> 00:03:33,450 Despite the strictness of this feature, it's prevalent among rust developers. 47 00:03:34,020 --> 00:03:36,510 This behavior can be good for developers. 48 00:03:36,750 --> 00:03:41,790 It forces us to handle all scenarios if we forget a possible value. 49 00:03:42,000 --> 00:03:44,580 The compiler will warn us ahead of time. 50 00:03:45,150 --> 00:03:50,820 You may want this behavior when working on large applications as your application grows. 51 00:03:51,000 --> 00:03:54,390 It's possible to overlook a pattern in your control flow. 52 00:03:54,720 --> 00:03:57,270 Russ can warn us when this problem happens. 53 00:03:57,660 --> 00:03:59,460 Let's handle a false pattern. 54 00:03:59,700 --> 00:04:05,250 If the free shipping variable is false or going to update the total variable by five. 55 00:04:07,780 --> 00:04:12,910 The free shipping variable is false, thus we should charge the buyer for shipping. 56 00:04:13,210 --> 00:04:16,440 They haven't met our threshold at the end of the function. 57 00:04:16,510 --> 00:04:18,550 Let's print the total variable. 58 00:04:18,850 --> 00:04:24,470 Keep in mind, the print line macro will not output numbers unless we format the string. 59 00:04:24,760 --> 00:04:26,560 Let's compile our project. 60 00:04:29,050 --> 00:04:30,610 It looks like I'm out of luck. 61 00:04:30,880 --> 00:04:33,970 My total is below the threshold for a free shipping. 62 00:04:34,360 --> 00:04:36,790 I'll have to pay for shipping on my purchase. 63 00:04:37,090 --> 00:04:39,370 As you can see, our app works. 64 00:04:39,610 --> 00:04:43,720 We were able to update the total variable with a match expression. 65 00:04:44,050 --> 00:04:49,210 As I stated before, it's possible to exclusively stick with conditional statements. 66 00:04:49,480 --> 00:04:53,140 However, matches are more useful for their strictness. 67 00:04:53,560 --> 00:04:55,930 We can take our expression a step further. 68 00:04:56,260 --> 00:04:58,720 The match keyword creates an expression. 69 00:04:58,990 --> 00:05:03,640 As a reminder, expressions are pieces of code that evaluate a value. 70 00:05:03,940 --> 00:05:11,230 For example, arithmetic operations are expressions such as the return value in the add function. 71 00:05:11,560 --> 00:05:14,410 The match keyword can return a value. 72 00:05:14,950 --> 00:05:20,500 Theoretically, we can refactor our current solution to update the total variable. 73 00:05:20,800 --> 00:05:22,330 Let me show you what I mean. 74 00:05:22,720 --> 00:05:29,410 Instead of updating the total variable in the patterns, we can move the assignment outside the match 75 00:05:29,410 --> 00:05:30,190 expression. 76 00:05:32,950 --> 00:05:39,250 This code will result in the same behavior, the values returned by our patterns will be returned by 77 00:05:39,250 --> 00:05:40,090 the expression. 78 00:05:40,360 --> 00:05:43,420 Thus, the total variable will be updated. 79 00:05:43,720 --> 00:05:46,510 We can run our compiler to view the results. 80 00:05:49,070 --> 00:05:55,520 As you can see, everything works like before you're more than free to use the previous solution, in 81 00:05:55,520 --> 00:05:56,310 my opinion. 82 00:05:56,330 --> 00:05:58,670 I think this solution is more readable. 83 00:05:59,270 --> 00:06:03,710 It's clear that we're trying to update the total variable based on a condition. 84 00:06:04,010 --> 00:06:05,750 Match expressions seem great. 85 00:06:05,900 --> 00:06:07,010 So what's the catch? 86 00:06:07,610 --> 00:06:11,060 If we have unlimited patterns, we need to handle them all. 87 00:06:11,390 --> 00:06:18,500 The current expression will have two possible values either the free shipping variable is true or false. 88 00:06:18,830 --> 00:06:20,810 It can't be any other value. 89 00:06:21,230 --> 00:06:23,360 What if we run a match against a number? 90 00:06:23,570 --> 00:06:26,980 Let's find out below the first match expression. 91 00:06:26,990 --> 00:06:30,230 Let's perform a match against the total variable. 92 00:06:32,830 --> 00:06:39,610 Inside the expression, we'll check if the variables match the numbers one or two in both patterns will 93 00:06:39,610 --> 00:06:40,870 output a message. 94 00:06:45,760 --> 00:06:51,940 There is an infinite amount of numbers the compiler is complaining we haven't accounted for all patterns. 95 00:06:52,150 --> 00:06:53,230 But how can we? 96 00:06:53,410 --> 00:06:56,680 We don't have time to enter every number imaginable. 97 00:06:57,040 --> 00:07:00,220 Luckily, the match operator has us covered. 98 00:07:00,520 --> 00:07:07,540 We can insert a wildcard character to catch patterns we haven't added inside the block at an underscore 99 00:07:07,540 --> 00:07:11,500 character, the underscore character as a fallback pattern. 100 00:07:11,770 --> 00:07:16,450 If the match operator cannot find a match, the code from this pattern will run. 101 00:07:16,960 --> 00:07:22,330 And this example, we will print a message that says the following no match found. 102 00:07:24,870 --> 00:07:26,610 Let's compile our project. 103 00:07:29,010 --> 00:07:35,610 As you can see, the match operator was not able to find a match and defaulted to the underscore pattern. 104 00:07:36,030 --> 00:07:40,290 There's a lot more we can do with matches, but this information will suffice. 105 00:07:40,590 --> 00:07:45,360 There are a couple more topics I want to cover before moving onto WebAssembly. 106 00:07:45,720 --> 00:07:47,730 I'll see you in the next lecture.