Rewrite lifetimes section #607

mdinger · 2015-06-28T05:05:02Z

~~[WIP]~~

I tried pretty hard to make it read decently (I'm not that great at it though). Hopefully it is.
~~I completely glossed over elision and I may just insert a link to the book section where it discusses elision...not sure~~
I tried to give answers to most of the questions asked on this users thread but I'm not sure what they are all asking exactly.
These examples are mostly simple. I'm not sure what kind of concepts the more complex ones use.

[TODO]

Need to add See also sections
~~This reddit thread details a more advanced example which I don't get yet. Maybe I'll look at it again later.~~ [Defer to later]
~~Some testcases might be nice.~~ [Defer to later]

[EDIT]

Added a section on lifetime coercion
Added a section on elision. It's pretty brief and then defers to the book.

Fixes #154

rust-highfive · 2015-06-28T05:05:08Z

r? @steveklabnik

(rust_highfive has picked a reviewer for you, use r? to override)

mdinger · 2015-06-30T21:59:43Z

r? @steveklabnik

I think this is ready for review. I accidentally messed up my commit history so I went ahead and started new and rebased.

steveklabnik · 2015-06-30T22:13:28Z

examples/scope/lifetime/elision/input.md

@@ -0,0 +1,14 @@
+Some lifetime patterns are overwelmingly common and so they may be elide


mdinger · 2015-07-03T21:18:45Z

@steveklabnik r?

I tweaked a bunch of stuff but a lot of it is still the same. I'd happily squash to 1 or 2 commits if you like it as is but want fewer commits.

tomjakubowski · 2015-07-06T07:13:17Z

cc #613 (I see that this pull request resolves that by adding a section on lifetime bounds)

nikomatsakis · 2015-07-07T16:40:55Z

examples/scope/lifetime/explicit/input.md

-write would look like this:
+Since lifetimes *currently* have no explicit type or name associated with them,
+usage will require generics (similar to [closures][anonymity]). Somewhat
+peculiarly, lifetime annotation has a second additional meaning. `foo<'a, 'b>`


This is not really how I think of it. I presume foo<'a,'b> refers to a type? In that case, foo<'a, 'b> is just as simple as "foo, where 'a and 'b are substituted for the lifetime parameters within the definition", just as Vec<i32> is "Vec, where i32 is substituted for the type parameter in the definition". Now, it is also true that if you have foo<'a ,'b>, this type can only be referenced where 'a and 'b are in scope, so that implies that the structure is limited by the minimum of 'a and 'b.

Yes, foo<'a, 'b> is meant to represent a type such as a struct or a function or something else.

That makes sense and I think I can tweak it to use a different approach. I've been generally explaining struct Num(i32) declarations and usage independently. This has worked okay so far. A better approach might be to introduce struct Ref<'a>(&'a i32) via a "ref is subordinate to owner" approach (the ref must come from somewhere but I've kinda ignored that part).

I'll try it and see if I can improve it.

@nikomatsakis I tweaked it to be more like you suggested.

mdinger · 2015-07-10T04:34:01Z

examples/scope/lifetime/explicit/explicit.rs

+    // cannot be coerced into a larger one.
+    //
+    //let y: &'a i32 = &_x;
+    // ERROR: `_x` does not live long enough
 }


@nikomatsakis This function above was slightly problematic with your suggested explanation since you cannot rely on input borrowing being returned and deduce the lifetime requirements from that.

To be honest, this function makes no sense at all -- a random lifetime parameter that is not used anywhere is not particularly useful or meaningful. (Really, it ought to be illegal.)

That said, I don't quite follow how this example is in conflict with the explanation I suggested. I'm not even 100% sure what explanation you're referring to :). I thought I was explaining how to interpret a type like Foo<'a>, which does not appear in this example, right?

But in any case, the existing text is correct: whatever scope 'a corresponds to (and, given that 'a is completely unused, the caller can pick whatever scope they can name), it will be something larger than the current function, and _x is SMALLER than the current function, so this code is in error.

Ah, this explanation. Anyway, the rules for Foo<'a> as a struct or foo<'a> as a function are basically the same. Rather than try to explain the same thing twice once for structs and once for functions, I tried to use foo<'a, 'b> as a stand-in for both. Maybe it wasn't successful...

Good. If the explanation is okay then I'm okay with it. As for this example being random...it's not really. It's due to trying the obvious thing following an unhelpful error message. Consider this:

fn test() { let x: &'a i32 = &7; }

Error:

<anon>:1:21: 1:23 error: use of undeclared lifetime name `'a` [E0261] <anon>:1 fn test() { let x: &'a i32 = &7; }

Oh, it needs declaring. Let's try:

fn test<'a>() { let x: &'a i32 = &7; }

Error:

<anon>:1:35: 1:36 error: borrowed value does not live long enough <anon>:1 fn test<'a>() { let x: &'a i32 = &7; }

Hmm...is manual annotation of lifetimes possible?

mdinger · 2015-07-10T21:21:16Z

Made another slight tweak based on @nikomatsakis's comment. I'm not sure if I should keep asking for r? after fixing things or what. Or who I should be asking...

@nikomatsakis @alexcrichton Thanks for critiquing so far. Both your comments/critiques have been helpful. Especially @nikomatsakis.

mdinger · 2015-07-15T03:29:10Z

Rebased

mdinger · 2015-07-16T19:50:20Z

If someone could list an ETA for review by Friday that would be helpful to me. Stuff doesn't happen much over the weekends usually.

mdinger · 2015-07-24T04:51:26Z

It has been a week. Review would still be nice. Maybe some things still need changes but I'm not sure how I should change them.

mdinger · 2015-07-30T19:08:54Z

Still looking for review. It's been another week. Just trying to keep this from being forgotten.

steveklabnik · 2015-07-31T17:07:35Z

with the run up to rustcamp, i am very behind. Sorry :(

steveklabnik · 2015-08-07T14:32:35Z

@mdinger hoping to get to this sometime today, we'll see with the release

mdinger · 2015-08-07T17:12:38Z

That would be so great! I'd pretty much given up on someone reviewing this.

steveklabnik · 2015-08-11T18:51:21Z

Actually finally reviewing this. built it locally, reading now.

steveklabnik · 2015-08-11T18:52:19Z

examples/scope/lifetime/explicit/input.md

-annotated. These functions are generic and we must tell the compiler what is
-the relationship between the lifetimes of the objects that appear in the
-arguments and the output.
+The borrow checker utilizes explicit lifetime annotation to reason about


I would say 'annotations" here, which is a small difference, but makes it way easier for me to parse.

steveklabnik · 2015-08-11T18:54:35Z

examples/scope/lifetime/explicit/explicit.rs

+
+    // Borrows (`&`) of both variables are passed into the function.
+    // If a borrow is truly a borrow, the variable must be returned,
+    // otherwise a borrow would be transferring ownership. This means


I would make this sentence

When you pass a function a borrow as an argument, the borrow ends at the end of the function. The alternative to passing a borrow would be trasnferring ownership.

I don't like this change. As written, I'm trying to leverage the idea that people understand that borrows must always come back. If they don't come back then they can't be borrows; they must be something else. It's the only option. Then, a transfer would make perfect sense.

With your suggestion, I would immediately ask "why must they be returned"? I wouldn't necessarily see any reason they must be returned other than that is what the docs say.

The issue is that you don't return, like

fn foo<'a>(&'a i32)

Does not return anything, but is just fine. You don't need to explicitly return the reference.

I'm not talking about explicit returning. I'm talking about doing something which would preclude the reference from ever being able to return to it's owner. For example, if I tried this:

// Would this be the lifetime drawing? fn foo<'a>(a: &'a NonCopyType) { // ---| // | let var = *a; // ------------------| ... bar(var); }

Why would it fail? Well, it would force a move but a move can't be done with a borrow. Why not? Because that would make it something other than a borrow. I consider this related to lifetime size. foo() above has lifetime size which must be at least as large as the function.

Why must this lifetime size be larger than the function? Because borrows must always be returnable. The borrow being returned at the end is just a minor point you could learn after this is realized.

@steveklabnik Should I just find you on IRC tomorrow to try and hash out what to do about this section?

Maybe yeah. I"m not sure how much I'll be on. Still thinking about this.

steveklabnik · 2015-08-11T19:10:10Z

Whew! Done. I think this is definitely an improvement, just some nits.

mdinger · 2015-08-11T19:11:31Z

Okay cool. I'll try to get the changes fixed quickly. I'd like this to land if possible.

mdinger · 2015-08-11T20:13:47Z

Fixed

mdinger · 2015-08-14T20:09:33Z

rebased

Rewrite lifetimes section

steveklabnik · 2015-08-15T14:01:44Z

I'm still not 100% sure about that one example, but this has been sitting around forever, and I want to get it landed.

Thanks again for being patient @mdinger ❤️

mdinger · 2015-08-15T17:10:46Z

woooo!

@steveklabnik @nikomatsakis @alexcrichton Thanks for reviewing even if only for a little while!

rust-highfive assigned steveklabnik Jun 28, 2015

mdinger force-pushed the lifetimes branch from 8b8b8b4 to 9c3cc4c Compare June 30, 2015 21:38

mdinger changed the title ~~[WIP] Rewrite lifetimes section~~ Rewrite lifetimes section Jun 30, 2015

mdinger force-pushed the lifetimes branch from 921e25c to 5160f72 Compare June 30, 2015 21:58

steveklabnik reviewed Jun 30, 2015
View reviewed changes

nikomatsakis reviewed Jul 7, 2015
View reviewed changes

mdinger force-pushed the lifetimes branch 2 times, most recently from 61f8388 to b8a2aeb Compare July 10, 2015 04:31

mdinger reviewed Jul 10, 2015
View reviewed changes

mdinger force-pushed the lifetimes branch from b8a2aeb to f698a52 Compare July 10, 2015 21:14

mdinger force-pushed the lifetimes branch from f698a52 to eceddd7 Compare July 15, 2015 03:28

mdinger mentioned this pull request Aug 8, 2015

Example of traits' use of bounds includes previously un-described syntax #627

Closed

steveklabnik reviewed Aug 11, 2015
View reviewed changes

mdinger added 5 commits August 14, 2015 15:59

Rewrite lifetimes section

59d7609

Many slight lifetime tweaks

1c69d79

Additional lifetime tweaks

2f01a63

Fix most of steves nits

b22ba2e

Rephrase explicit lifetime comment

dfce986

mdinger force-pushed the lifetimes branch from 0832d4e to dfce986 Compare August 14, 2015 20:05

steveklabnik added a commit that referenced this pull request Aug 15, 2015

Merge pull request #607 from mdinger/lifetimes

89531ba

Rewrite lifetimes section

steveklabnik merged commit 89531ba into rust-lang:master Aug 15, 2015

mdinger deleted the lifetimes branch August 15, 2015 17:10

mdinger mentioned this pull request Oct 31, 2015

Irrefutable details in lifetime_bounds #656

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rewrite lifetimes section #607

Rewrite lifetimes section #607

mdinger commented Jun 28, 2015

rust-highfive commented Jun 28, 2015

mdinger commented Jun 30, 2015

steveklabnik Jun 30, 2015

mdinger Jul 1, 2015

mdinger commented Jul 3, 2015

tomjakubowski commented Jul 6, 2015

nikomatsakis Jul 7, 2015

mdinger Jul 7, 2015

mdinger Jul 10, 2015

mdinger Jul 10, 2015

nikomatsakis Jul 10, 2015

mdinger Jul 10, 2015

mdinger commented Jul 10, 2015

mdinger commented Jul 15, 2015

mdinger commented Jul 16, 2015

mdinger commented Jul 24, 2015

mdinger commented Jul 30, 2015

steveklabnik commented Jul 31, 2015

steveklabnik commented Aug 7, 2015

mdinger commented Aug 7, 2015

steveklabnik commented Aug 11, 2015

steveklabnik Aug 11, 2015

steveklabnik Aug 11, 2015

mdinger Aug 11, 2015

steveklabnik Aug 11, 2015

mdinger Aug 11, 2015

mdinger Aug 14, 2015

steveklabnik Aug 14, 2015

steveklabnik commented Aug 11, 2015

mdinger commented Aug 11, 2015

mdinger commented Aug 11, 2015

mdinger commented Aug 14, 2015

steveklabnik commented Aug 15, 2015

mdinger commented Aug 15, 2015

		@@ -0,0 +1,14 @@
		Some lifetime patterns are overwelmingly common and so they may be elide

Rewrite lifetimes section #607

Rewrite lifetimes section #607

Conversation

mdinger commented Jun 28, 2015

rust-highfive commented Jun 28, 2015

mdinger commented Jun 30, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdinger commented Jul 3, 2015

tomjakubowski commented Jul 6, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdinger commented Jul 10, 2015

mdinger commented Jul 15, 2015

mdinger commented Jul 16, 2015

mdinger commented Jul 24, 2015

mdinger commented Jul 30, 2015

steveklabnik commented Jul 31, 2015

steveklabnik commented Aug 7, 2015

mdinger commented Aug 7, 2015

steveklabnik commented Aug 11, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

steveklabnik commented Aug 11, 2015

mdinger commented Aug 11, 2015

mdinger commented Aug 11, 2015

mdinger commented Aug 14, 2015

steveklabnik commented Aug 15, 2015

mdinger commented Aug 15, 2015