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.

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

Expliciting lifetime in the first example #351

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Arthur-Milchior
Copy link
Contributor

@Arthur-Milchior Arthur-Milchior commented May 5, 2022

The main issue with having three lets one after the other, is that it's not
clear if the lifetime created due to let x is the one before or after this
line. Assuming I understood correctly what's going on, this example will clarify
that the lifetime is created after the let. I also add a note stating what the
usual notation is and warning that this longer explicit lifetime name is used
only once for the sake of being as clear as possible.

Other solutions I considered would be to add a "print" between two lets, this
will ensure that the lifetime introduction is near a single "let", hence making
it clear which "let" is concerned by the lifetime.

If I got it wrong and actually the scope is introduced before the let statement,
I guess at least this confirms that clarification may be helpful.

If the sake of clarity is more important than the sake of tradition, I'm willing to spend the time needed to add more explicit lifetime name to the other examples

The main issue with having three lets one after the other, is that it's not
clear if the lifetime created due to `let x` is the one before or after this
line. Assuming I understood correctly what's going on, this example will clarify
that the lifetime is created after the let. I also add a note stating what the
usual notation is and warning that this longer explicit lifetime name is used
only once for the sake of being as clear as possible.

Other solutions I considered would be to add a "print" between two lets, this
will ensure that the lifetime introduction is near a single "let", hence making
it clear which "let" is concerned by the lifetime.

If I got it wrong and actually the scope is introduced before the let statement,
I guess at least this confirms that clarification may be helpful.
Copy link
Member

@JohnTitor JohnTitor left a comment

Choose a reason for hiding this comment

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

I don't think changing lifetime names on later examples is easy to read, saying like "'a implies the global lifetime" should be enough.
Note that the nomicon is less of a book for newcomers, that should defer to "the book" or something else.

@Arthur-Milchior
Copy link
Contributor Author

I've read the book, and I must admit that, as far as I understand, it did not go in such gritty details as to indicate whether the lifetime technically starts before or after a variable declaration. Not that this distinction seemed useful in normal use of rust as far as I understand.
If this was not in the book, I thought having one very detailed example could help.

Would it be okay to not only state that 'a is global, but

'a implies the global lifetime, 'b is the lifetime of x, and so on. That is, each lifetime begins immediately after the declaration.

src/lifetimes.md Outdated Show resolved Hide resolved
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
@Arthur-Milchior
Copy link
Contributor Author

I beg your pardon, does "waiting-on-review" mean you wait for another reviewer, or that you wait for me to do a change?
I was waiting for an answer to my last question before potentially updating this PR

Comment on lines +65 to +68
Wow. That's... awful. Let's all take a moment to thank Rust for making this
easier. To make matter worse, traditionally, lifetimes are not as descriptive
and simply called `'a`, `'b`, and so on. We will respect this tradition going
forward.
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this change is much helpful for readers and worth rephrasing so. As stated in the intro, we assume readers have a basic knowledge of Rust, actually, https://doc.rust-lang.org/nightly/book/ch10-03-lifetime-syntax.html#lifetime-annotation-syntax explains it and that should be enough.

Comment on lines -50 to +59
// NOTE: `'a: {` and `&'b x` is not valid syntax!
'a: {
// NOTE: `'global_lifetime: {` and `&'x_lifetime x` is not valid syntax!
'global_lifetime: {
let x: i32 = 0;
'b: {
// lifetime used is 'b because that's good enough.
let y: &'b i32 = &'b x;
'c: {
// ditto on 'c
let z: &'c &'b i32 = &'c y;
'x_lifetime: {
// lifetime used is 'x_lifetime because that's good enough.
let y: &'x_lifetime i32 = &'x_lifetime x;
'y_lifetime: {
// ditto on 'y_lifetime
let z: &'y_lifetime &'x_lifetime i32 = &'y_lifetime y;
Copy link
Member

Choose a reason for hiding this comment

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

After some re-thinking of this, I still think this is too descriptive. We easily can find 'a is a lifetime and curly braces are scopes if we're familiar with Rust's syntax. That is, naming lifetimes looks redundant, and tweaking prior wording should be enough here.

@JohnTitor
Copy link
Member

JohnTitor commented May 29, 2022

I beg your pardon, does "waiting-on-review" mean you wait for another reviewer, or that you wait for me to do a change? I was waiting for an answer to my last question before potentially updating this PR

It implies a PR is waiting on review. I was going to do a second review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants