Skip to content

Typo in ownership guide #19585

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 9, 2014
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions src/doc/guide-ownership.md
Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,7 @@ must have a deallocation for each allocation. Rust handles this for you. It
knows that our handle, `x`, is the owning reference to our box. Rust knows that
`x` will go out of scope at the end of the block, and so it inserts a call to
deallocate the memory at the end of the scope. Because the compiler does this
for us, it's impossible to forget. We always exaclty one deallocations paired
for us, it's impossible to forget. We always have exactly one deallocation paired
with each of our allocations.

This is pretty straightforward, but what happens when we want to pass our box
Expand Down Expand Up @@ -186,11 +186,11 @@ This function takes ownership, because it takes a `Box`, which owns its
contents. But then we give ownership right back.

In the physical world, you can give one of your possessions to someone for a
short period of time. You still own your posession, you're just letting someone
short period of time. You still own your possession, you're just letting someone
else use it for a while. We call that 'lending' something to someone, and that
person is said to be 'borrowing' that something from you.

Rust's ownershp system also allows an owner to lend out a handle for a limited
Rust's ownership system also allows an owner to lend out a handle for a limited
period. This is also called 'borrowing.' Here's a version of `add_one` which
borrows its argument rather than taking ownership:

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

Rust has a feature called 'lifetime elision,' which allows you to not write
lifetime annotations in certain circumstances. This is one of them. Without
eliding the liftimes, `add_one` looks like this:
eliding the lifetimes, `add_one` looks like this:

```rust
fn add_one<'a>(num: &'a int) -> int {
Expand All @@ -254,7 +254,7 @@ This part _declares_ our lifetimes. This says that `add_one` has one lifetime,
fn add_two<'a, 'b>(...)
```

Then in our parameter list, we use the liftimes we've named:
Then in our parameter list, we use the lifetimes we've named:

```{rust,ignore}
...(num: &'a int) -> ...
Expand All @@ -279,7 +279,7 @@ fn main() {
}
```

As you can see, `struct`s can also have liftimes. In a similar way to functions,
As you can see, `struct`s can also have lifetimes. In a similar way to functions,

```{rust}
struct Foo<'a> {
Expand All @@ -295,7 +295,7 @@ x: &'a int,
# }
```

uses it. So why do we need a liftime here? We need to ensure that any reference
uses it. So why do we need a lifetime here? We need to ensure that any reference
to a `Foo` cannot outlive the reference to an `int` it contains.

## Thinking in scopes
Expand Down