Clarification of borrowck

Author: Arthur-Milchior

src/borrow-splitting.md

@@ -1,10 +1,10 @@
 # Splitting Borrows
 
 The mutual exclusion property of mutable references can be very limiting when
-working with a composite structure. The borrow checker understands some basic
-stuff, but will fall over pretty easily. It does understand structs
-sufficiently to know that it's possible to borrow disjoint fields of a struct
-simultaneously. So this works today:
+working with a composite structure. The borrow checker (a.k.a. borrowck)
+understands some basic stuff, but will fall over pretty easily. It does
+understand structs sufficiently to know that it's possible to borrow disjoint
+fields of a struct simultaneously. So this works today:
 
 ```rust
 struct Foo {
@@ -23,8 +23,8 @@ let c2 = &x.c;
 println!("{} {} {} {}", a, b, c, c2);
 ```
 
-However borrowck doesn't understand arrays or slices in any way, so this doesn't
-work:
+However the borrow checker doesn't understand arrays or slices in any way, so
+this doesn't work:
 
 ```rust,compile_fail
 let mut x = [1, 2, 3];
@@ -48,17 +48,17 @@ error[E0499]: cannot borrow `x[..]` as mutable more than once at a time
 error: aborting due to previous error
 ```
 
-While it was plausible that borrowck could understand this simple case, it's
-pretty clearly hopeless for borrowck to understand disjointness in general
-container types like a tree, especially if distinct keys actually *do* map
-to the same value.
-
-In order to "teach" borrowck that what we're doing is ok, we need to drop down
-to unsafe code. For instance, mutable slices expose a `split_at_mut` function
-that consumes the slice and returns two mutable slices. One for everything to
-the left of the index, and one for everything to the right. Intuitively we know
-this is safe because the slices don't overlap, and therefore alias. However
-the implementation requires some unsafety:
+While it was plausible that the borrow checker could understand this simple
+case, it's pretty clearly hopeless for the borrow checker to understand
+disjointness in general container types like a tree, especially if distinct keys
+actually *do* map to the same value.
+
+In order to "teach" the borrow checker that what we're doing is ok, we need to
+drop down to unsafe code. For instance, mutable slices expose a `split_at_mut`
+function that consumes the slice and returns two mutable slices. One for
+everything to the left of the index, and one for everything to the
+right. Intuitively we know this is safe because the slices don't overlap, and
+therefore alias. However the implementation requires some unsafety:
 
 ```rust
 # use std::slice::from_raw_parts_mut;