Skip to content
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

Jump to bottom

Book: Be very explicit of lifetimes being descriptive #36997

Merged
merged 5 commits into from
Oct 12, 2016
Merged

Book: Be very explicit of lifetimes being descriptive #36997

Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
2130637
Book: Be very explicit of lifetimes being descriptive
KillTheMule Oct 6, 2016
7f02eb3
Distinguish lifetimes and their annotations
KillTheMule Oct 6, 2016
a542302
Another shot at clarity
KillTheMule Oct 6, 2016
2a0bd6d
Typos
KillTheMule Oct 6, 2016
0d0cdb7
Wrap & improve
KillTheMule Oct 7, 2016
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
2 changes: 2 additions & 0 deletions src/doc/book/lifetimes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,6 +56,8 @@ To fix this, we have to make sure that step four never happens after step
three. The ownership system in Rust does this through a concept called
lifetimes, which describe the scope that a reference is valid for.

**Note** It's important to understand that lifetime annotations are _descriptive_, not _prescriptive_. This means that how long a reference is valid is determined by the code, not by the annotations. The annotations, however, point out this fact to the compiler in case it can't figure it out by itself.
Copy link
Member

Choose a reason for hiding this comment

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

Could you wrap this to 80 columns please?

Copy link
Member

Choose a reason for hiding this comment

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

The annotations, however, point out this fact to the compiler in case it can't figure it out by itself.

So, the compiler doesn't try to "figure out" the right lifetimes; it only applies the elision rules, which are just dumb patterns. So I would change this to something like,

The annotations, however, give the compiler the information it needs for more complex cases.

Or something like that. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So, the compiler doesn't try to "figure out" the right lifetimes; it only applies the elision rules, which are just dumb patterns.

I don't really understand the inner workings of the compiler, but my thinking goes like this: Lifetime rules are for figuring out if it's ok do drop a certain value at the point where it goes out of scope (i.e. it's owner). For that, I assume the compiler does a "control lifetimes" pass, and if that's ok, it forgets about them and translates the code as is, without resorting to any lifetime anymore (this is what this is about, you can't influence the machine code by lifetimes, ony if it compiles or not). Elision let's the programmer leave out certain annotation, but that "just" means the compiler puts them in itself. After elision, it still has the "real work" of checking.

In that way, lifetime annotations "help the compiler figure out if the code is ok to compile".

Is that correct? I'll try to improve my wording, but I'll change it if my thoughts aren't correct.

Copy link
Member

Choose a reason for hiding this comment

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

Elision let's the programmer leave out certain annotation, but that "just" means the compiler puts them in itself. After elision, it still has the "real work" of checking.

Yes, that's correct.


When we have a function that takes an argument by reference, we can be
implicit or explicit about the lifetime of the reference:

Expand Down