@@ -93,7 +93,7 @@ must have a deallocation for each allocation. Rust handles this for you. It
93
93
knows that our handle, ` x ` , is the owning reference to our box. Rust knows that
94
94
` x ` will go out of scope at the end of the block, and so it inserts a call to
95
95
deallocate the memory at the end of the scope. Because the compiler does this
96
- for us, it's impossible to forget. We always exaclty one deallocations paired
96
+ for us, it's impossible to forget. We always have exactly one deallocation paired
97
97
with each of our allocations.
98
98
99
99
This is pretty straightforward, but what happens when we want to pass our box
@@ -186,11 +186,11 @@ This function takes ownership, because it takes a `Box`, which owns its
186
186
contents. But then we give ownership right back.
187
187
188
188
In the physical world, you can give one of your possessions to someone for a
189
- short period of time. You still own your posession , you're just letting someone
189
+ short period of time. You still own your possession , you're just letting someone
190
190
else use it for a while. We call that 'lending' something to someone, and that
191
191
person is said to be 'borrowing' that something from you.
192
192
193
- Rust's ownershp system also allows an owner to lend out a handle for a limited
193
+ Rust's ownership system also allows an owner to lend out a handle for a limited
194
194
period. This is also called 'borrowing.' Here's a version of ` add_one ` which
195
195
borrows its argument rather than taking ownership:
196
196
@@ -231,7 +231,7 @@ fn add_one(num: &int) -> int {
231
231
232
232
Rust has a feature called 'lifetime elision,' which allows you to not write
233
233
lifetime annotations in certain circumstances. This is one of them. Without
234
- eliding the liftimes , ` add_one ` looks like this:
234
+ eliding the lifetimes , ` add_one ` looks like this:
235
235
236
236
``` rust
237
237
fn add_one <'a >(num : & 'a int ) -> int {
@@ -254,7 +254,7 @@ This part _declares_ our lifetimes. This says that `add_one` has one lifetime,
254
254
fn add_two<'a, 'b>(...)
255
255
```
256
256
257
- Then in our parameter list, we use the liftimes we've named:
257
+ Then in our parameter list, we use the lifetimes we've named:
258
258
259
259
``` {rust,ignore}
260
260
...(num: &'a int) -> ...
@@ -279,7 +279,7 @@ fn main() {
279
279
}
280
280
```
281
281
282
- As you can see, ` struct ` s can also have liftimes . In a similar way to functions,
282
+ As you can see, ` struct ` s can also have lifetimes . In a similar way to functions,
283
283
284
284
``` {rust}
285
285
struct Foo<'a> {
@@ -295,7 +295,7 @@ x: &'a int,
295
295
# }
296
296
```
297
297
298
- uses it. So why do we need a liftime here? We need to ensure that any reference
298
+ uses it. So why do we need a lifetime here? We need to ensure that any reference
299
299
to a ` Foo ` cannot outlive the reference to an ` int ` it contains.
300
300
301
301
## Thinking in scopes
0 commit comments