Borrowing Solution

[00:00:00]
>> So once again, we get the use after move error, but this time we know an easier way to fix this, which is to say I'm going to ask these to accept references to x rather than regular x. And I'm gonna go ahead and do that for average too cuz it's much quicker than the return value juggling we were doing before.

[00:00:22]
And now it's gonna give me a different error, which is mismatch types say expected a reference, but I actually found a sort of a non reference VEC. Consider borrowing here, well, thank you very much, I will consider borrowing here, that's exactly what I wanna do. So there we go, and now everything works, excellent.

[00:00:39]
So let's run this and we get exactly the same answer as before, with a much cleaner solution than what we had before with the return value juggling and also without having to do cloning. Okay, so that was the first way of doing this, but we can also have this except a slice, so here's what that'll look like.

[00:01:02]
So it'll be bracket I64. Now you can iterate over slices exactly the same way as VEC. So this part fortunately will not be any different in terms of what it's doing, no problem there. And you won't be surprised to see that now, I can actually just run this exactly normally I didn't actually have to call like .asslice.

[00:01:27]
And the reason for this is that rust has as a convenience, whenever you have a function that accepts a reference, sorry a slice, you can actually just give it a borrowed VEC and it will go ahead and translate those. The way that it does that is actually using traits which again we're not gonna cover in this workshop, we only have one more section it's gonna be about lifetimes.

[00:01:48]
But if you're curious this is not actually something that's sort of like hard coded baked into the compiler this is actually a little trick you can do yourself. With your own types to basically make it so that when you borrow a particular type, you can make it sort of translated into multiple or compatible with multiple different reference types like this.

[00:02:07]
Okay, questions about this exercise?
>> I am curious if you do hard code the slice and give it parameters for what you wanna cut, if the VEC changes the length and you have too many numbers now like you've included too many what will happen?
>> Great question. I don't think I've ever actually tried that.

[00:02:30]
What would I expect to happen? I certainly would expect a panic, but I'm not sure when. [LAUGH] So I'm reasonably confident the answer will be you'll get a panic somewhere, but I'm not sure. I guess it would be probably when you try to Iterate over the slice. Actually, I take that back.

[00:02:56]
So because of the rules that we talked about previously, if I already have an immutable borrow active on this thing, I actually wouldn't be able to change the contents of the VEC because that would require having a mutable reference to it. And if I have a mutable reference, I couldn't also at the same time have an immutable reference via the slice.

[00:03:16]
So it wouldn't be possible to have a slice to a VEC and then change its length, or change the length of the vector after a while that slice still exists or is still active. However I could like just runway off the end here like this, and that will definitely either not compile or panic depending on whether it's a slice of an array or a VEC.

[00:03:39]
But yeah, it shouldn't actually be possible to compile a recipe against successfully that has that problem.