Skip to content

Update ownership.md for clarity #428

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.

Sign up for GitHub

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

Open
gdennie wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update ownership.md for clarity #428

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
17 changes: 10 additions & 7 deletions src/ownership.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,9 +41,9 @@ be forced to accept your program on the assumption that it is correct.
This will never happen to Rust. It's up to the programmer to prove to the
compiler that everything is sound.

Of course, Rust's story around ownership is much more complicated than just
verifying that references don't escape the scope of their referent. That's
because ensuring pointers are always valid is much more complicated than this.
Of course, Rust's story around ownership is much more complicated than simply
gauranteeing that references cannot outlive their target. That is
Copy link
Contributor

@julian-graf julian-graf Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
gauranteeing that references cannot outlive their target. That is
guaranteeing that references cannot outlive their target. That is

because ensuring pointers are always valid in the general case is much more complicated.
For instance in this code,

```rust,compile_fail
Expand All @@ -59,7 +59,10 @@ data.push(4);
println!("{}", x);
```

naive scope analysis would be insufficient to prevent this bug, because `data`
does in fact live as long as we needed. However it was *changed* while we had
a reference into it. This is why Rust requires any references to freeze the
referent and its owners.
a naive scope analysis would be insufficient to prevent this bug because `data`
does indeed live as long as required. However, `data` is *changed* by `push(4)`
and now may have been realocated to accommodate the new value.
Copy link
Contributor

@julian-graf julian-graf Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
and now may have been realocated to accommodate the new value.
and now may have been reallocated to accommodate the new value.

Consequently, `x` may now be referring to the old
value or memory already put to use in another process (pre-emptive multi-tasking).
Comment on lines +65 to +66
Copy link
Contributor

@julian-graf julian-graf Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going into detail this far (another process & preemptive multitasking) is misleading in multiple ways:

  • the actual issue of accessing free'd memory is not mentioned
  • accessing free'd memory is UB
  • another process & preemptive multitasking is not a requirement
Suggested change
Consequently, `x` may now be referring to the old
value or memory already put to use in another process (pre-emptive multi-tasking).
Consequently, the memory location pointed to by `x` may now be free'd and therefore any attempt to dereference `x` is UB.

This is why Rust requires the code to also treat the target as frozen; and so,
will refuse the expression, `data.push(4)`.