Alice Ryhl

And a reference is basically, all it is, is that it's a pointer to the object,

And that's it.

So we do no checking at runtime.

So, of course, this means that compile time, we have to make sure that the last use of the reference has to be before the object goes out of scope.

And creating a reference is called borrowing, right?

The owner owns the value.

And now we have a borrow of the value, the reference.

And the borrow checkout checks that the reference is borrowed.

Like the last use of the reference is before the object goes out of scope.

So if you have, say, let's say you have an immutable reference you're reading, then if you change the object, let's say it's in vector.

So I have an immutable reference I'm reading element five, and then I change the vector I call clear.

Then the borrow checker also ensures that you can't use the reference to object five afterwards.

Yeah, the way it works is that if there are mutable borrows, it ensures that the mutable borrow ends or starts before or after the previous borrows have ended, basically, so they don't overlap.

So you can only have one writer at the time, or you can have any number of readers.

It checks that on the scope, like in a function.

When you write some code that uses the object in a way that doesn't follow the rules I mentioned, that's a compiler error.

And fighting the borrow checker is when you can't get out of those compiler errors, I guess.

I think a lot of the time this has to do with the struct.

One common mistake I see is that if you have a struct with a reference in it, Rust kind of assumes that it can check

the scope of that reference by just looking at a single function.