1 00:00:06,580 --> 00:00:08,040 - Now we're gonna talk about constants 2 00:00:08,040 --> 00:00:10,990 and constants are really a fascinating part 3 00:00:10,990 --> 00:00:13,510 of the language for me, because of the way 4 00:00:13,510 --> 00:00:14,900 they're implemented, and again remember 5 00:00:14,900 --> 00:00:17,330 Go is all about these costs and these trade offs 6 00:00:17,330 --> 00:00:19,620 so let's talk about the mechanics around 7 00:00:19,620 --> 00:00:21,150 constants I find them really interesting 8 00:00:21,150 --> 00:00:23,430 and I'll show you some of the cooler aspects 9 00:00:23,430 --> 00:00:25,920 of constants and how they work in the language. 10 00:00:25,920 --> 00:00:27,960 You'll end up using a few of them 11 00:00:27,960 --> 00:00:29,910 in almost every program that you write. 12 00:00:31,330 --> 00:00:33,910 Alright, so one of the really interesting things 13 00:00:33,910 --> 00:00:36,800 about constants, for me is that 14 00:00:36,800 --> 00:00:39,910 they only exist at compile time. 15 00:00:39,910 --> 00:00:41,030 Constants 16 00:00:42,516 --> 00:00:43,570 are 17 00:00:43,570 --> 00:00:47,330 something that really have a much different feel 18 00:00:47,330 --> 00:00:50,140 and flavor to than your common variables. 19 00:00:50,140 --> 00:00:53,050 Look at this right here on line 15 and 16. 20 00:00:53,050 --> 00:00:55,260 I am declaring two constants, but these 21 00:00:55,260 --> 00:00:57,560 are constants of a kind, and that's usually 22 00:00:57,560 --> 00:00:59,650 thing I've only seen it, seen it like this 23 00:00:59,650 --> 00:01:01,550 in this language. 24 00:01:01,550 --> 00:01:02,850 Most of the time we think about constants 25 00:01:02,850 --> 00:01:05,230 as being read-only variables, 26 00:01:05,230 --> 00:01:07,510 and it's absolutely not the case in Go. 27 00:01:07,510 --> 00:01:09,900 So, when we look at constants, they can come 28 00:01:09,900 --> 00:01:13,000 into this flavor that you see here, that is of a kind. 29 00:01:13,000 --> 00:01:14,760 Notice that there's no type information 30 00:01:14,760 --> 00:01:18,960 during the declaration of these constants on line 15 or 16. 31 00:01:18,960 --> 00:01:22,020 And again, it's based on the value on the right hand side 32 00:01:22,020 --> 00:01:24,460 of this assignment, whether they will be of kind 33 00:01:24,460 --> 00:01:26,600 integer or kind float. 34 00:01:26,600 --> 00:01:29,450 Right below there, just to show you the contrast, 35 00:01:29,450 --> 00:01:32,630 those are constants of a type, of type int 36 00:01:32,630 --> 00:01:34,830 and of type float64. 37 00:01:34,830 --> 00:01:37,200 Now, the big difference between constants of a kind 38 00:01:37,200 --> 00:01:40,110 and of a type, are that constants of a kind 39 00:01:40,110 --> 00:01:44,400 can be implicitly converted by the compiler. 40 00:01:44,400 --> 00:01:46,370 This gets really interesting, remember we talked about 41 00:01:46,370 --> 00:01:47,910 during the struct types, that there's no 42 00:01:47,910 --> 00:01:50,750 implicit conversion of that concrete data, 43 00:01:50,750 --> 00:01:53,833 but when we start talking about constants of a kind, 44 00:01:54,900 --> 00:01:56,310 that goes out the door. 45 00:01:56,310 --> 00:01:58,830 Now, constants of a type still hold true 46 00:01:58,830 --> 00:02:01,040 that once something is of a type, 47 00:02:01,040 --> 00:02:03,980 then that's it, the implicit conversion goes away. 48 00:02:03,980 --> 00:02:07,460 But constants of a kind, there we get some flexibility 49 00:02:07,460 --> 00:02:09,270 and it's a very powerful mechanism in Go, 50 00:02:09,270 --> 00:02:11,300 I'll show you from code readability. 51 00:02:11,300 --> 00:02:14,130 So there we go, ui, uf, two constants of a kind, 52 00:02:14,130 --> 00:02:17,180 kind int, kind float, and ti and tf, 53 00:02:17,180 --> 00:02:20,450 constants of type int and type float. 54 00:02:20,450 --> 00:02:22,460 Now, if we continue to talk about 55 00:02:22,460 --> 00:02:26,750 the idea of these kinds and what happens there, 56 00:02:26,750 --> 00:02:28,710 there's something very special in Go, 57 00:02:28,710 --> 00:02:31,890 and it's called Kind Promotion. 58 00:02:31,890 --> 00:02:34,100 And this Kind Promotion will tell you 59 00:02:34,100 --> 00:02:37,267 how things promote so floats promote over ints 60 00:02:37,267 --> 00:02:40,670 and types always promote over kind. 61 00:02:40,670 --> 00:02:43,610 So, on line 24, and I had to comment that out 62 00:02:43,610 --> 00:02:47,600 because once I made that constant of a type Uint8 63 00:02:47,600 --> 00:02:50,270 it was bound by the laws of type 64 00:02:50,270 --> 00:02:52,340 and you could only put a value 65 00:02:52,340 --> 00:02:55,390 within the scope of a one biter 8-bit integer. 66 00:02:55,390 --> 00:02:57,030 But what's also really interesting about 67 00:02:57,030 --> 00:02:59,960 constants of a kind, because they're not type based, 68 00:02:59,960 --> 00:03:02,913 they're technically not limited by precision, 69 00:03:03,760 --> 00:03:08,290 and if you look at the specification, 70 00:03:08,290 --> 00:03:13,110 if you look at the specification around constants of a kind, 71 00:03:13,110 --> 00:03:15,830 you'll notice that the specification says 72 00:03:15,830 --> 00:03:20,810 that a constant has to be at least of 256 bits 73 00:03:20,810 --> 00:03:21,750 of precision. 74 00:03:21,750 --> 00:03:25,510 That makes constants of a kind almost like, 75 00:03:25,510 --> 00:03:27,620 or the compiler when it comes to constants of a kind 76 00:03:27,620 --> 00:03:31,240 like a high precision calculator. 77 00:03:31,240 --> 00:03:34,428 Now, if you look at on line 30 78 00:03:34,428 --> 00:03:36,720 I want to show you some very interesting things here. 79 00:03:36,720 --> 00:03:40,300 What we're doing is we're multiplying the value of three 80 00:03:40,300 --> 00:03:42,510 by the value of 0.333. 81 00:03:42,510 --> 00:03:44,330 On the surface we see that we have an integer 82 00:03:44,330 --> 00:03:45,720 and we have a floating point. 83 00:03:45,720 --> 00:03:48,150 Remember, you can't have an implicit conversion 84 00:03:48,150 --> 00:03:49,470 between two different types. 85 00:03:49,470 --> 00:03:51,140 We could argue that these are two different types 86 00:03:51,140 --> 00:03:53,420 an int and a float, but they're constants, 87 00:03:53,420 --> 00:03:55,810 literal values in Go are constants, 88 00:03:55,810 --> 00:03:57,130 they're constants of a kind, 89 00:03:57,130 --> 00:04:00,850 they're technically unnamed constants of a kind. 90 00:04:00,850 --> 00:04:04,210 And so through this idea of Kind Promotion, 91 00:04:04,210 --> 00:04:08,910 that kind integer three will be promoted up to kind float. 92 00:04:08,910 --> 00:04:13,570 We now have like kind on both sides of that multiplication 93 00:04:13,570 --> 00:04:16,630 and var at this point is variable ends up being 94 00:04:16,630 --> 00:04:19,530 a variable of that float64 type. 95 00:04:19,530 --> 00:04:21,860 Very, very interesting, powerful stuff 96 00:04:21,860 --> 00:04:23,770 where we were able to work with literal values 97 00:04:23,770 --> 00:04:25,730 from a kind perspective, we don't have to worry about 98 00:04:25,730 --> 00:04:28,800 doing any explicit conversions 99 00:04:28,800 --> 00:04:31,240 and then this promotion takes care of making sure 100 00:04:31,240 --> 00:04:32,680 that everything is right. 101 00:04:32,680 --> 00:04:36,140 But remember that we're dealing with 256 of precision, 102 00:04:36,140 --> 00:04:39,270 256 bits of precision when we're dealing with 103 00:04:39,270 --> 00:04:42,540 constants of a kind, and when we now convert us back 104 00:04:42,540 --> 00:04:44,350 to a variable where you see answer, 105 00:04:44,350 --> 00:04:46,710 we're moving that down to a 64 bit level of precision. 106 00:04:46,710 --> 00:04:48,450 There will be some precision loss, 107 00:04:48,450 --> 00:04:50,770 but again, remember that floating points 108 00:04:50,770 --> 00:04:53,800 already are already not precise, right, 109 00:04:53,800 --> 00:04:56,330 IEEE754 binary decimals. 110 00:04:56,330 --> 00:04:59,510 Look on line 33, this time we're doing division 111 00:04:59,510 --> 00:05:04,510 between basically a kind int1 and a kind float3.0. 112 00:05:04,760 --> 00:05:05,930 Again, we get the same thing, 113 00:05:05,930 --> 00:05:09,080 that integer promotes up to be of kind float, 114 00:05:09,080 --> 00:05:11,270 and we actually what we would say is 115 00:05:11,270 --> 00:05:15,700 have the exact representation of 1/3. 116 00:05:15,700 --> 00:05:18,410 Sometimes, in the old days we used to call 117 00:05:18,410 --> 00:05:21,490 what we considered constants of a kind to be exact, 118 00:05:21,490 --> 00:05:23,470 they were like these very exact numbers 119 00:05:23,470 --> 00:05:26,750 because we had such high levels of precision 120 00:05:26,750 --> 00:05:28,870 that they were exact. 121 00:05:28,870 --> 00:05:31,480 So, we would look at third truly as 1/3 122 00:05:32,977 --> 00:05:35,307 even though, eventually it turns to 56 bits 123 00:05:35,307 --> 00:05:37,710 but there be some precision loss. 124 00:05:37,710 --> 00:05:39,910 But then on line 36 you could see that 125 00:05:39,910 --> 00:05:41,750 there's no promotion going on. 126 00:05:41,750 --> 00:05:44,510 One is of kind int, three is of kind int, 127 00:05:44,510 --> 00:05:47,270 we do the division, we end up with zero, 128 00:05:47,270 --> 00:05:48,520 because that's what's that's gonna be, 129 00:05:48,520 --> 00:05:50,950 everything stays within the kind integer. 130 00:05:50,950 --> 00:05:54,860 Now, I also told you that we can promote from kind to type 131 00:05:54,860 --> 00:05:56,740 and look at this on line 40. 132 00:05:56,740 --> 00:05:59,540 We're creating a constant of type int8 133 00:05:59,540 --> 00:06:01,100 reside in the value of one, 134 00:06:01,100 --> 00:06:03,940 so it's still a constant, still only exists at compile time, 135 00:06:03,940 --> 00:06:06,330 but it's bound by the int8 type. 136 00:06:06,330 --> 00:06:09,760 And now this is where the power of kind and type comes in. 137 00:06:09,760 --> 00:06:11,720 Look on line 41. 138 00:06:11,720 --> 00:06:15,010 We're taking the literal value of kind int2 139 00:06:15,010 --> 00:06:18,240 multiplying it by the constant of int8, 140 00:06:18,240 --> 00:06:20,300 and now, again, through promotion, 141 00:06:20,300 --> 00:06:23,550 that kind 2 value promotes up to int8, 142 00:06:23,550 --> 00:06:26,170 it now promotes to be a type constant. 143 00:06:26,170 --> 00:06:28,360 Again, we've got to have those like types 144 00:06:28,360 --> 00:06:30,500 across, you know, that expression, 145 00:06:30,500 --> 00:06:35,230 and two ends up being a constant of type int8. 146 00:06:35,230 --> 00:06:39,370 So these are the mechanics of constants of a kind, 147 00:06:39,370 --> 00:06:41,970 constants of a type, and the promotion, 148 00:06:41,970 --> 00:06:45,423 and I want to show you how powerful this stuff is. 149 00:06:46,790 --> 00:06:49,440 But before we do, I want to show you as well 150 00:06:49,440 --> 00:06:53,070 that this idea that constants only exist at compile time 151 00:06:53,070 --> 00:06:54,910 and they have these high precisions, 152 00:06:54,910 --> 00:06:59,040 like a minimum of 256 bits of precision is real. 153 00:06:59,040 --> 00:07:01,880 Now, it's hard to show you this is real when things 154 00:07:01,880 --> 00:07:04,670 only exist at compile time and we have to run a program 155 00:07:04,670 --> 00:07:07,150 at run time, but I want you to look at these constants 156 00:07:07,150 --> 00:07:08,510 as I've declared. 157 00:07:08,510 --> 00:07:10,830 This constant is called maxInt 158 00:07:10,830 --> 00:07:14,450 and it represents the maximum signed integer you could have 159 00:07:14,450 --> 00:07:17,740 for a 64 bit precision, there it is. 160 00:07:17,740 --> 00:07:22,370 But look on line 14, I'm storing a much larger number there, 161 00:07:22,370 --> 00:07:26,000 much larger than our 64 bit variables could ever hold. 162 00:07:26,000 --> 00:07:27,570 Now these are integers, but again, 163 00:07:27,570 --> 00:07:29,860 we have 256 bits of precision. 164 00:07:29,860 --> 00:07:33,090 If we didn't have these higher levels of precision, 165 00:07:33,090 --> 00:07:35,940 we really wouldn't be able to do this assignment at all. 166 00:07:35,940 --> 00:07:39,010 So what I'm really gonna show you is, as I run this, 167 00:07:39,010 --> 00:07:42,330 the compiler accepts line 14 even though 168 00:07:42,330 --> 00:07:43,650 this is a much larger number 169 00:07:43,650 --> 00:07:44,910 we could ever put in a variable. 170 00:07:44,910 --> 00:07:48,490 I mean look, if I take this and say 171 00:07:48,490 --> 00:07:52,660 let's create a constant of type int64 with the same number, 172 00:07:52,660 --> 00:07:56,160 this won't compile, that number is much larger 173 00:07:56,160 --> 00:07:58,580 than a 64 bit can hold 174 00:07:58,580 --> 00:08:01,620 and I've still only scratched the surface 175 00:08:01,620 --> 00:08:03,810 on what I could store in this constant. 176 00:08:03,810 --> 00:08:07,060 I mean I can keep going, I've got 256 bits 177 00:08:07,060 --> 00:08:08,910 of precision here. 178 00:08:08,910 --> 00:08:12,320 So, the compiler is really like this high precision 179 00:08:12,320 --> 00:08:14,770 calculator when it comes to constants. 180 00:08:14,770 --> 00:08:17,740 Let me show you more practical use of constants 181 00:08:17,740 --> 00:08:19,575 and how this kind and type promotion 182 00:08:19,575 --> 00:08:22,323 really makes our life a little bit better. 183 00:08:23,240 --> 00:08:25,860 Look at this constant tier of type Duration. 184 00:08:25,860 --> 00:08:28,480 This is a second way to declare a type here in Go, 185 00:08:28,480 --> 00:08:32,610 what I would say is, the name type Duration is based, 186 00:08:32,610 --> 00:08:34,790 based on int64. 187 00:08:34,790 --> 00:08:38,290 This is not an alias, we have really two distinct 188 00:08:38,290 --> 00:08:40,000 named types here. 189 00:08:40,000 --> 00:08:43,040 We're just using int64 as our base information 190 00:08:43,040 --> 00:08:45,250 or our base memory model for Duration. 191 00:08:45,250 --> 00:08:46,700 And I only want to do these types of things 192 00:08:46,700 --> 00:08:50,020 when the new type has its own representation and meaning, 193 00:08:50,020 --> 00:08:52,330 and it does here in the time package. 194 00:08:52,330 --> 00:08:54,560 Duration represents time. 195 00:08:54,560 --> 00:08:58,070 Doesn't represent an int64, it represents 196 00:08:58,070 --> 00:09:00,510 nanoseconds of time. 197 00:09:00,510 --> 00:09:01,860 I want you to look at these constants 198 00:09:01,860 --> 00:09:04,320 'cause this is a real practical 199 00:09:04,320 --> 00:09:08,950 and clean way of how this idea of type 200 00:09:08,950 --> 00:09:10,920 and kind work together in constants. 201 00:09:10,920 --> 00:09:13,600 So we create a type constant named Nanosecond, 202 00:09:13,600 --> 00:09:16,480 which represents one nanosecond of time, 203 00:09:16,480 --> 00:09:19,410 it's based on a duration, and then if you go to line 16, 204 00:09:19,410 --> 00:09:20,490 look at what we're doing. 205 00:09:20,490 --> 00:09:25,460 We're taking the literal value of kind int1000, 206 00:09:25,460 --> 00:09:28,930 this is a constant, an unnamed constant of kind int, 207 00:09:28,930 --> 00:09:33,160 we're multiplying it by our type constant Nanosecond, 208 00:09:33,160 --> 00:09:35,510 this gets promoted to be of type Duration, 209 00:09:35,510 --> 00:09:38,450 and we end up with another constant of type Duration. 210 00:09:38,450 --> 00:09:39,620 How amazing is this? 211 00:09:39,620 --> 00:09:42,150 This looks simple on the surface, 212 00:09:42,150 --> 00:09:45,420 but the engineering behind this is really, really powerful. 213 00:09:45,420 --> 00:09:47,540 In fact, all of these constants end up being 214 00:09:47,540 --> 00:09:52,050 of type Duration, and represent the proper int64 value 215 00:09:52,050 --> 00:09:55,173 for these incremental units of time. 216 00:09:56,160 --> 00:09:57,690 And more gets into this. 217 00:09:57,690 --> 00:09:59,460 I mean look at this Add method. 218 00:09:59,460 --> 00:10:01,300 We will talk about methods later, 219 00:10:01,300 --> 00:10:03,400 but I want to focus on the parameter here. 220 00:10:03,400 --> 00:10:07,940 Notice how Add takes a value of type Duration, right. 221 00:10:07,940 --> 00:10:09,240 And we might do this, we might say 222 00:10:09,240 --> 00:10:13,300 I only want to pass Duration values into Add. 223 00:10:13,300 --> 00:10:14,840 Well, one of the interesting things about 224 00:10:14,840 --> 00:10:17,360 constants of a kind, again, is that they can be 225 00:10:17,360 --> 00:10:21,250 implicitly converted when there's compatibility. 226 00:10:21,250 --> 00:10:24,320 This is one of the first things that really messed with me 227 00:10:24,320 --> 00:10:26,200 when I started learning Go. 228 00:10:26,200 --> 00:10:27,760 I mean look at this, on line 39 229 00:10:27,760 --> 00:10:30,420 I called the now function of the time package 230 00:10:30,420 --> 00:10:34,270 and I create a variable which gives me the current time. 231 00:10:34,270 --> 00:10:36,770 Now when I call Add on line 42, 232 00:10:36,770 --> 00:10:39,350 notice I'm passing the literal, 233 00:10:39,350 --> 00:10:42,610 unnamed constant of kind int 234 00:10:42,610 --> 00:10:44,190 minus five. 235 00:10:44,190 --> 00:10:46,040 You might say, whoa, whoa, whoa, whoa, whoa, 236 00:10:46,040 --> 00:10:48,160 that's not of type Duration, what's going on, 237 00:10:48,160 --> 00:10:50,230 why would the compiler accept that? 238 00:10:50,230 --> 00:10:51,900 This is one of those trade offs 239 00:10:51,900 --> 00:10:54,230 because values of a kind, right, 240 00:10:54,230 --> 00:10:57,170 constants of a kind, can be implicitly converted, 241 00:10:57,170 --> 00:10:59,100 we can pass that in, it would represent 242 00:10:59,100 --> 00:11:02,980 minus five nanoseconds, and this would really mess you up. 243 00:11:02,980 --> 00:11:04,680 This is one of the reasons why we can't have 244 00:11:04,680 --> 00:11:06,610 enumerations in Go. 245 00:11:06,610 --> 00:11:08,950 We don't want to create types as aliases 246 00:11:08,950 --> 00:11:11,540 to get compiler protection when they're based 247 00:11:11,540 --> 00:11:13,350 on let's say, those built-in types, 248 00:11:13,350 --> 00:11:15,240 which is where constants are allowed to be. 249 00:11:15,240 --> 00:11:18,730 Constants can only be based on the built-in types 250 00:11:18,730 --> 00:11:21,970 because again, they only exist at compile time. 251 00:11:21,970 --> 00:11:23,780 But look at this, this is something that we're gonna do 252 00:11:23,780 --> 00:11:27,420 a lot in Go, the timeout constant, right. 253 00:11:27,420 --> 00:11:30,730 Five is of kind int, there it is, 254 00:11:30,730 --> 00:11:33,130 time.Second is of type Duration, 255 00:11:33,130 --> 00:11:36,650 it's still a constant, but it's a constant of type Duration, 256 00:11:36,650 --> 00:11:39,290 that five int kind promotes up to Duration 257 00:11:39,290 --> 00:11:42,220 and timeout becomes a constant of type Duration, 258 00:11:42,220 --> 00:11:44,160 and that constant of type Duration 259 00:11:44,160 --> 00:11:46,840 supports the API very, very cleanly. 260 00:11:46,840 --> 00:11:49,800 This is really nice and great API design 261 00:11:49,800 --> 00:11:51,950 in leveraging constants of a type 262 00:11:51,950 --> 00:11:54,130 and constants of a kind. 263 00:11:54,130 --> 00:11:56,330 Very, very powerful stuff. 264 00:11:56,330 --> 00:11:59,010 The one thing you could never do is what we see here. 265 00:11:59,010 --> 00:12:02,900 Notice that I'm converting our integer, right, 266 00:12:02,900 --> 00:12:05,920 our constant minus five of kind int 267 00:12:05,920 --> 00:12:10,010 into a variable, or a value of type int64. 268 00:12:10,010 --> 00:12:12,470 I cannot pass minus five to Add 269 00:12:12,470 --> 00:12:16,190 because that is a value based on a name type int64 270 00:12:16,190 --> 00:12:17,730 and it only wants Duration. 271 00:12:17,730 --> 00:12:19,630 So those constants of a kind can be 272 00:12:19,630 --> 00:12:21,820 implicitly converted through those calls, 273 00:12:21,820 --> 00:12:23,570 any value that's based on a type, 274 00:12:23,570 --> 00:12:27,290 we've got to have like types everywhere, everywhere. 275 00:12:27,290 --> 00:12:30,610 Very, very interesting and powerful stuff around constants. 276 00:12:30,610 --> 00:12:32,540 Now there's one last thing about constants 277 00:12:32,540 --> 00:12:35,670 that you'll probably want to use as you're writing 278 00:12:35,670 --> 00:12:36,913 production level code. 279 00:12:38,210 --> 00:12:41,460 This is the idea of the keyword iota, I-O-T-A. 280 00:12:41,460 --> 00:12:42,930 It's really interesting and it can be 281 00:12:42,930 --> 00:12:45,600 very, very confusing at first. 282 00:12:45,600 --> 00:12:48,530 If you notice that I'm using the concept of a block, 283 00:12:48,530 --> 00:12:50,670 we can do this with vars and types 284 00:12:50,670 --> 00:12:52,930 and we do it with imports all the time. 285 00:12:52,930 --> 00:12:55,530 Notice that we're using the parentheses here 286 00:12:55,530 --> 00:12:59,470 to block a bunch of, in this case, constants, 287 00:12:59,470 --> 00:13:01,800 so I don't have to write const again over and over again. 288 00:13:01,800 --> 00:13:04,940 And this iota stuff works very, very well 289 00:13:04,940 --> 00:13:06,310 when it comes to constants. 290 00:13:06,310 --> 00:13:09,980 Now, when we start a block of constants like we did here, 291 00:13:09,980 --> 00:13:12,400 iota starts at the value of zero. 292 00:13:12,400 --> 00:13:14,870 And then every time we use it inside the block, 293 00:13:14,870 --> 00:13:17,110 it will increment by one. 294 00:13:17,110 --> 00:13:19,840 The output of this right here, if I just run it, 295 00:13:19,840 --> 00:13:23,050 you'll see here that it's zero, one, two. 296 00:13:23,050 --> 00:13:24,500 Zero, one, two. 297 00:13:24,500 --> 00:13:27,890 We get this incrementing feature for free 298 00:13:27,890 --> 00:13:29,950 inside the constant block. 299 00:13:29,950 --> 00:13:33,850 Now, most likely, because we want the incrementing feature, 300 00:13:33,850 --> 00:13:35,320 we're gonna do it like this. 301 00:13:35,320 --> 00:13:38,450 We only have to assign iota one time 302 00:13:38,450 --> 00:13:41,010 to the very first constant in the block 303 00:13:41,010 --> 00:13:44,700 and we will automatically, for free, get the incremental. 304 00:13:44,700 --> 00:13:48,000 Again, on the output here, we see here is 305 00:13:48,000 --> 00:13:51,100 two, zero, one, two, same exact output, 306 00:13:51,100 --> 00:13:53,670 the thing is I didn't have to repeat myself 307 00:13:53,670 --> 00:13:55,440 and keep putting iota there. 308 00:13:55,440 --> 00:13:58,400 Now, this is something also that you'll see a lot of. 309 00:13:58,400 --> 00:14:00,560 Maybe we don't want to start at zero, 310 00:14:00,560 --> 00:14:01,970 we want to start at one. 311 00:14:01,970 --> 00:14:04,140 So the first constant, we take we know 312 00:14:04,140 --> 00:14:06,500 what the starting point for iota is zero, 313 00:14:06,500 --> 00:14:10,140 incremented by one initially on that first constant, 314 00:14:10,140 --> 00:14:11,610 and then we'll start at one. 315 00:14:11,610 --> 00:14:14,110 One, two, and three. 316 00:14:14,110 --> 00:14:16,170 And, we do this in the log package, 317 00:14:16,170 --> 00:14:18,790 and sometimes what you want is a set of constants that 318 00:14:18,790 --> 00:14:22,440 bit precision in some sort of flagging system, 319 00:14:22,440 --> 00:14:24,140 like we do at login. 320 00:14:24,140 --> 00:14:25,490 Notice this time what we're doing 321 00:14:25,490 --> 00:14:30,270 is we're using the iota value to shift bits to the left one 322 00:14:30,270 --> 00:14:33,870 and that gives us one, two, four, eight, 16, 32. 323 00:14:33,870 --> 00:14:36,950 You might see that a lot with constants as well. 324 00:14:36,950 --> 00:14:39,660 So, this iota is a very powerful mechanism 325 00:14:39,660 --> 00:14:41,210 if you're creating a set of constants 326 00:14:41,210 --> 00:14:43,800 that are gonna have some unique IDs 327 00:14:43,800 --> 00:14:46,330 and it just kind of let's the language 328 00:14:46,330 --> 00:14:47,860 set all that up for you. 329 00:14:47,860 --> 00:14:50,800 So constants are really, really powerful in Go. 330 00:14:50,800 --> 00:14:53,040 Remember now that there's two types of constants, 331 00:14:53,040 --> 00:14:55,730 constants of a kind and constants of a type. 332 00:14:55,730 --> 00:14:58,670 Your literal values in Go are constants of a kind, 333 00:14:58,670 --> 00:15:01,350 they're unnamed constants, constants of a kind 334 00:15:01,350 --> 00:15:03,970 can be implicitly converted by the compiler, 335 00:15:03,970 --> 00:15:06,637 which means that you can't really have enumerations in Go. 336 00:15:06,637 --> 00:15:09,150 You're not gonna get those compiler protections. 337 00:15:09,150 --> 00:15:11,210 Once a compiler is based on a type, 338 00:15:11,210 --> 00:15:14,630 then the full laws of type are gonna restrict its ability 339 00:15:14,630 --> 00:15:17,800 to be anything other than its particular precision. 340 00:15:17,800 --> 00:15:19,390 Remember, constants of a kind can have up to 341 00:15:19,390 --> 00:15:22,100 256 bits of precision, we got really like a 342 00:15:22,100 --> 00:15:25,950 high precision calculator in Go. 343 00:15:25,950 --> 00:15:27,660 And then again, those literal values 344 00:15:27,660 --> 00:15:29,083 are all constants of a kind.