Fight the confusion over 'static #1316
Conversation
Many people learning Rust are confused by the fact that owned values are `'static`. I feel the description here as well as in _the book_ are responsible for that. I hope that this change makes things a lot clearer. Note that I have intersected the explanation before the existing example because if It's underneath, it will be offscreen without scrolling. I kind of feel this is to important to be hidden offscreen, even if I tried to reformulate the original text to be more accurate. I would propose we put this explanation in _the book_ as well, in the section about 'static lifetimes. For an example of what can happen if people are confused about lifetime bounds (and use unsafe): diem/diem#1949
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @marioidival (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
bors r? @steveklabnik It seems I modified your writing, so I suppose you probably want to have a look at whether you're ok with the change. |
| of the binary: | ||
| `'static` is one of the reserved lifetime specifiers. It has a special meaning | ||
| in Rust. A __reference__ that has a `'static` lifetime is guaranteed to be | ||
| valid for the entire lifetime of the running program. |
There was a problem hiding this comment.
This is not quite correct. It may live for the entire lifetime, but does not have to.
There was a problem hiding this comment.
Do you mean that if I had an API that takes in a &'static Something it would possibly stop being valid at some point before the end of the program? That seems problematic, no? How do you know when?
There was a problem hiding this comment.
There was a problem hiding this comment.
Ok, but now we are confusing with the lifetime of the variable binding of the reference. I generally assumed that when we speak about reference lifetimes, we mean the lifetime of the pointed to data and the one we name as in &'a SomeValue -> 'a in this case. The text says "the reference is guaranteed to be valid", as opposed to "The reference lives for ...". Of course you are allowed to drop it sooner if you don't need it anymore. Given that beginners will most often read the book, this is probably a bad assumption on my part.
But if you feel that that is still not clear enough, I will propose a complete rewrite. I am generally in favor of being very precise and thorough, but often my documentation PR's get downplayed, so I didn't necessarily proposed the way I like it best but more as what I estimate the general opinion might be. It will probably be a fair bit longer if trying to be complete. I suppose also that in RBE we prefer showing code rather than long descriptions?
| valid for the entire lifetime of the running program. | ||
|
|
||
| There are two ways to create data that lives for the entire lifetime of | ||
| a program and both are stored in the read-only memory of the binary: |
There was a problem hiding this comment.
This is also not the only two ways: owned values are 'static.
There was a problem hiding this comment.
The two points where there in the original text. The PR tries to make the distinction between 'static as a bound, which passes for owned data, and 'static on a reference. That's the whole point of a common confusion. Owned data AFAICT won't live for the entire lifetime of the program unless it is in a global. Otherwise it's always scoped, maybe to fn main() but still scoped.
I don't know if you are just reading the diff, it might be worth to zoom out and read both versions in their entirety.
|
Looking over it. Maybe the mistake is to try to fix the original text with minimal changes. The ways to make data that lives for the entire lifetime isn't very relevant unless you are taking a reference to them. So that might still be confusing. Maybe it's worth considering rewriting it from scratch with a little list of what we want to convey. All in all, because of the different meaning of |
Yeah, that may be true! Like I said, appreciate you taking a crack at it here. Hm. |
|
See follow up in #1320 |
Many people learning Rust are confused by the fact that owned values are
'static. I feel the description here as well as in the book are in part responsible for that.I hope that this change makes things a lot clearer. Note that I have intersected the explanation before the existing example because if It's underneath, it will
be offscreen without scrolling. I kind of feel this is to important to be hidden offscreen, even if I tried to reformulate the original text to be more accurate.
I would propose we put this explanation in the book as well, in the section about 'static lifetimes.
For an example of what can happen if people are confused about lifetime bounds (and use unsafe): diem/diem#1949
ps: edited on Github, so I didn't run this through mdbook and doctests... but the example was verified on the playground.