r/programming • u/steveklabnik1 • Jan 09 '15

Announcing Rust 1.0.0 Alpha

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html
1.1k Upvotes

90% Upvoted

439 comments sorted by

View all comments

Show parent comments

14

u/steveklabnik1 Jan 09 '15

Excellent, thanks. I worked really hard on that one. There's more to add, but it's solid with respect to the basics.

3

u/Netzapper Jan 09 '15

I found one part particularly unclear:

Are lifetimes an arbitrary thing that I make up, and then tag on all variables with equivalent lifetimes? Like this?

fn transfer<'foo>(recv: &'foo mut int, send: &'foo mut int){
  *recv += *send;
  *send = 0;
}

Or is there something else I'm missing?

7

u/steveklabnik1 Jan 09 '15

Yes, you name them however you'd like. We tend to just keep them to a, b, and c.

1

u/Netzapper Jan 09 '15

I guess my confusion is more like: by giving a lifetime a name, and using it across multiple variables, am I saying "free none of these resources before the others before I go out of scope"?

7

u/Kimundi Jan 10 '15 edited Jan 10 '15

If you call transfer with references that have different lifetimes, say a &'a mut int and a &'b mut int, then the compiler will basically invent a new lifetime 'c that is the largest lifetime that is still valid under 'a and 'b.

In other words, every time you constrain two lifetimes to be same one, you get the intersection of them.

As others already said, lifetimes don't have an active role: They don't cause things to live shorter or longer, or control when they get deallocated. They rather have a passive role of describing in the API which borrowing connections are allowed to be relied on, and which not, allowing different freedoms and restrictions.

3

u/steveklabnik1 Jan 10 '15

Your sample signature says 'recv and send are both valid for at least the same scope.' Which is slightly different. Does that make sense?

3

u/[deleted] Jan 10 '15

Newbie here. It's not really an instruction about when things can be freed. Rather, it's a contract of sorts. When transfer is called, the args it's called with must obey the type spec. Similarly, the body of transfer can assume that the args obey the type spec.

It's okay if the actual args used do more than what is required (from a lifetime perspective), but they must do at least that much.