Now that we've gone over ownership, we can talk about references and borrowing. Instead of moving our variable, let's use a reference. Here's our do stuff function again, only this time it takes a reference to a string. The ampersand before the type indicates a reference to type. When we call do stuff, we pass it a reference to s one. And s one retains ownership of the value, do stuff borrows a reference to the value, the reference not the value gets moved into the function.

At the end of the function, the reference goes out of scope and the reference gets dropped. So our borrowing ends at that point. After the function call, we can use s one like normal because the value never moved. Under the hood, when we create a reference to s one rust creates a pointer to s one. But you will almost never talk about pointers in rust because the language automatically handles their creation and design. For the most part and make sure they're always valid using a concept called lifetimes lifetimes can be summed up as a rule that references must always be valid, which means the compiler won't let you create a reference that outlives the data it is ultimately referencing and you can never point to no references default to immutable even if the value being referenced is immutable.

But if we make a mutable reference to a mutable value, then we can use the reference to change the value as well. The syntax for a mutable reference is a little special, ampersand, mute space, variable or type. Now wait, why didn't we have to dereference the mutable reference in order to alter s in the do stuff method? Look at this. We are using the same dot syntax to access a string method on a mutable reference, as we do for the value itself. How does that work?

The dot operator For a method or a field auto D references down to the actual value. So at least when you're dealing with a dot operator, you don't have to worry about whether something is a value or a reference or even a reference of a reference. If we manually dereferenced s, it would look like this. You use an asterisk immediately before a reference to dereference to the value similar to see, the dereference operator has pretty low precedence, so you'll sometimes need to use parentheses. With most other operators like the assignment operator, for example, you will need to manually dereference your reference if you want to read from or write to the actual value. Here, I'm dereferencing s so that I can replace the entire value.

So let's stop and go over what references look like. Again, if you have a variable x, then this creates an immutable reference to that variables value. And this creates a mutable reference to that variables value. Similarly with types, if this is the type of your value, then this is the type of your immutable reference. And this is the type of your mutable reference. going the other way around.

If your variable is a mutable reference to a value, then dereferencing x gives you mutable access to the value. And if x is an immutable reference to a value, then dereferencing x gives you immutable access to the value. Naturally, since references are implemented via pointers rust has a special rule to keep us safe. At any given time, you can have either exactly one mutable reference, or any number of immutable references. This rule applies across all threads. When you consider that references to a variable many exists in different threads.

It starts to make it pretty obvious why it's not safe to have multiple mutable references to the same variable at the same time without some type of locking But if all the references are immutable, then there's no problem. So you can have lots of immutable references spread across multiple threads. All these rules I've been talking about are enforced by the compiler. And by enforced I mean compiler errors, lots of compiler errors. At first, you're like, ah, I hate the compiler keeps giving me errors. But then as you get the hang of it, you realize you don't get mysterious seg faults anymore.

And the error messages are really pretty informative. And if the code compiles, it works and that is an amazing feeling. In the next video, we'll learn about structs