Skip to content

Commit 796e4b8

Browse files
committed
Typo
1 parent 6f4c11b commit 796e4b8

File tree

1 file changed

+7
-7
lines changed

1 file changed

+7
-7
lines changed

Diff for: src/doc/guide-ownership.md

+7-7
Original file line numberDiff line numberDiff line change
@@ -93,7 +93,7 @@ must have a deallocation for each allocation. Rust handles this for you. It
9393
knows that our handle, `x`, is the owning reference to our box. Rust knows that
9494
`x` will go out of scope at the end of the block, and so it inserts a call to
9595
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
9797
with each of our allocations.
9898

9999
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
186186
contents. But then we give ownership right back.
187187

188188
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
190190
else use it for a while. We call that 'lending' something to someone, and that
191191
person is said to be 'borrowing' that something from you.
192192

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
194194
period. This is also called 'borrowing.' Here's a version of `add_one` which
195195
borrows its argument rather than taking ownership:
196196

@@ -231,7 +231,7 @@ fn add_one(num: &int) -> int {
231231

232232
Rust has a feature called 'lifetime elision,' which allows you to not write
233233
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:
235235

236236
```rust
237237
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,
254254
fn add_two<'a, 'b>(...)
255255
```
256256

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:
258258

259259
```{rust,ignore}
260260
...(num: &'a int) -> ...
@@ -279,7 +279,7 @@ fn main() {
279279
}
280280
```
281281

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,
283283

284284
```{rust}
285285
struct Foo<'a> {
@@ -295,7 +295,7 @@ x: &'a int,
295295
# }
296296
```
297297

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
299299
to a `Foo` cannot outlive the reference to an `int` it contains.
300300

301301
## Thinking in scopes

0 commit comments

Comments
 (0)