---

yaml
---
r: 275004
b: refs/heads/stable
c: a6fedc8
h: refs/heads/master

Author: sandeep-datta

[refs]

@@ -29,7 +29,7 @@ refs/heads/tmp: e06d2ad9fcd5027bcaac5b08fc9aa39a49d0ecd3
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: c0221c8897db309a79990367476177b1230bb264
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: a8fd1bbd2f9511e9394fed1112c4ada186eb1b00
+refs/heads/stable: a6fedc85bfec568a404c4a78d9c7faef12937695
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375
 refs/tags/1.1.0: bc3c16f09287e5545c1d3f76b7abd54f2eca868b
 refs/tags/1.2.0: f557861f822c34f07270347b94b5280de20a597e

branches/stable/src/doc/book/ownership.md

@@ -148,12 +148,12 @@ on the [heap][sh] for the actual data (`[1, 2, 3]`). Rust copies the address
 of this heap allocation to an internal pointer, which is part of the vector
 object placed on the stack (let's call it the data pointer). 
 
-It is worth pointing out (even at the risk of repeating things) that the vector
-object and its data live in separate memory regions instead of being a single
-contiguous memory allocation (due to reasons we will not go into at this point
-of time). These two parts of the vector (the one on the stack and one on the
-heap) must agree with each other at all times with regards to things like the
-length, capacity etc.
+It is worth pointing out (even at the risk of stating the obvious) that the
+vector object and its data live in separate memory regions instead of being a
+single contiguous memory allocation (due to reasons we will not go into at
+this point of time). These two parts of the vector (the one on the stack and
+one on the heap) must agree with each other at all times with regards to
+things like the length, capacity etc.
 
 When we move `v` to `v2`, rust actually does a bitwise copy of the vector
 object `v` into the stack allocation represented by `v2`. This shallow copy
@@ -169,7 +169,7 @@ For example if we truncated the vector to just two elements through `v2`:
 v2.truncate(2);
 ```
 
-and `v1` were still accessible we'd end up with an invalid vector since it
+and `v1` were still accessible we'd end up with an invalid vector since `v1`
 would not know that the heap data has been truncated. Now, the part of the
 vector `v1` on the stack does not agree with the corresponding part on the
 heap. `v1` still thinks there are three elements in the vector and will