Skip to content

Commit 363ed2f

Browse files
committed
Correct minor typos on the ownership guide.
liftimes -> lifetimes
1 parent 6f4c11b commit 363ed2f

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

src/doc/guide-ownership.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -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)