//@ reference, Rust knows that it cannot mutate `v`. Hence the pointer into the buffer of `v`
//@ that was created before calling `vec_min` remains valid.
-// ## Exclusive, mutable references
-//@ There is a second way to borrow something, a second kind of reference: The *exclusive reference*. This is a reference that comes with the promise that
+// ## Unique, mutable references
+//@ There is a second way to borrow something, a second kind of reference: The *unique reference*. This is a reference that comes with the promise that
//@ nobody else has *any kind of access* to the referee - there is no aliasing. As a consequence, it is always safe to mutate data through
-//@ an exclusive reference, which is why they are usually called *mutable references*.
+//@ an unique reference, which is why they are usually called *mutable references*.
//@ As an example, consider a function which increments every element of a vector by 1.
//@ The type `&mut Vec<i32>` is the type of mutable references to `vec<i32>`. Because the reference is
-//@ mutable, we can use a mutable iterator, providing mutable (exclusive) references to the elements.
+//@ mutable, we can use a mutable iterator, providing mutable (unique) references to the elements.
fn vec_inc(v: &mut Vec<i32>) {
for e in v.iter_mut() {
*e += 1;
Text(String),
}
//@ Now consider the following piece of code. Like above, `n` will be a reference to a part of `var`,
-//@ and since we wrote `ref mut`, the reference will be exclusive and mutable. In other words, right after the match, `ptr`
+//@ and since we wrote `ref mut`, the reference will be uniqie and mutable. In other words, right after the match, `ptr`
//@ points to the number that's stored in `var`, where `var` is a `Number`. Remember that `_` means
//@ "we don't care".
fn work_on_variant(mut var: Variant, text: String) {
//@ When analyzing the code of `rust_foo`, Rust has to assign a lifetime to `first`. It will choose the scope
//@ where `first` is valid, which is the entire rest of the function. Because `head` ties the lifetime of its
//@ argument and return value together, this means that `&v` also has to borrow `v` for the entire duration of
-//@ the function `rust_foo`. So when we try to borrow `v` exclusively for `push`, Rust complains that the two references (the one
-//@ for `head`, and the one for `push`) overlap. Lucky us! Rust caught our mistake and made sure we don't crash the program.
+//@ the function `rust_foo`. So when we try to create a unique reference to `v` for `push`, Rust complains that the two references (the one
+//@ for `head`, and the one for `push`) overlap, so neither of them can be unique. Lucky us! Rust caught our mistake and made sure we don't crash the program.
//@
//@ So, to sum this up: Lifetimes enable Rust to reason about *how long* a reference is valid, how long ownership has been borrowed. We can thus
//@ safely write functions like `head`, that return references into data they got as argument, and make sure they
//@ is a shared reference. However, it has to increment the reference count! Internally, `Rc` uses `Cell` for the count, such that it
//@ can be updated during `clone`.
//@
-//@ Putting it all together, the story around mutation and ownership through references looks as follows: There are *exclusive* references,
+//@ Putting it all together, the story around mutation and ownership through references looks as follows: There are *unique* references,
//@ which - because of their exclusivity - are always safe to mutate through. And there are *shared* references, where the compiler cannot
//@ generally promise that mutation is safe. However, if extra circumstances guarantee that mutation *is* safe, then it can happen even
//@ through a sahred reference - as we saw with `Cell`.
//@ the check will always succeed, as is actually entirely useless. However, this is not actually true. Several different `CallbacksMut` could share
//@ a callback (as they were created with `clone`), and calling one callback here could trigger calling
//@ all callbacks of the other `CallbacksMut`, which would end up calling the initial callback again. This issue of functions accidentally recursively calling
- //@ themselves is called *reentrancy*, and it can lead to subtle bugs. Here, it would mean that the closure runs twice, each time thinking it has an
- //@ exclusive, mutable reference to its environment - so it may end up dereferencing a dangling pointer. Ouch! Lucky enough,
+ //@ themselves is called *reentrancy*, and it can lead to subtle bugs. Here, it would mean that the closure runs twice, each time thinking it has a
+ //@ unique, mutable reference to its environment - so it may end up dereferencing a dangling pointer. Ouch! Lucky enough,
//@ Rust detects this at run-time and panics once we try to borrow the same environment again. I hope this also makes it
//@ clear that there's absolutely no hope of Rust performing these checks statically, at compile-time: It would have to detect reentrancy!
let mut closure = callback.borrow_mut();
// Finally, we split our slice to sort the two halves. The nice part about slices is that splitting them is cheap:
//@ They are just a pointer to a start address, and a length. We can thus get two pointers, one at the beginning and
//@ one in the middle, and set the lengths appropriately such that they don't overlap. This is what `split_at_mut` does.
- //@ Since the two slices don't overlap, there is no aliasing and we can have both of them as exclusive, mutable slices.
+ //@ Since the two slices don't overlap, there is no aliasing and we can have both of them as unique, mutable slices.
let (part1, part2) = data.split_at_mut(lpos);
//@ The index operation can not only be used to address certain elements, it can also be used for *slicing*: Giving a range
//@ of indices, and obtaining an appropriate part of the slice we started with. Here, we remove the last element from
//@ In part 13, we talked about types that are marked `Send` and thus can be moved to another thread. However, we did *not*
//@ talk about the question whether a reference is `Send`. For `&mut T`, the answer is: It is `Send` whenever `T` is send.
//@ `&mut` allows moving values back and forth, it is even possible to [`swap`](https://doc.rust-lang.org/stable/std/mem/fn.swap.html)
-//@ the contents of two mutable references. So in terms of concurrency, sending a mutable, exclusive reference is very much like
+//@ the contents of two mutable references. So in terms of concurrency, sending a mutable, unique reference is very much like
//@ sending full ownership, in the sense that it can be used to move the object to another thread.
//@
//@ But what about `&T`, a shared reference? Without interior mutability, it would always be all-right to send such values.
//@ the data in the list lives at least as long as the iterator: If you drop the `T: 'a`, Rust will tell
//@ you to add it back. And secondly, Rust will complain if `'a` is not actually used in the struct.
//@ It doesn't know what it is supposed to do with that lifetime. So we use `PhantomData` again to tell
-//@ it that in terms of ownership, this type actually (exclusively) borrows a linked list. This has no
+//@ it that in terms of ownership, this type actually (uniquely) borrows a linked list. This has no
//@ operational effect, but it means that Rust can deduce the intent we had when adding that
//@ seemingly useless lifetime parameter.
pub struct IterMut<'a, T> where T: 'a {
println!("The first element is: {}", *first);
}
-// ## Exclusive, mutable references
+// ## Unique, mutable references
fn vec_inc(v: &mut Vec<i32>) {
for e in v.iter_mut() {
projects / rust-101.git / commitdiff