3 ms·

Regarding the first point, about scope, I'd guess he's referring to lifetimes and how you can explicitly annotate that something can live as long as another thi

Regarding the first point, about scope, I'd guess he's referring to lifetimes and how you can explicitly annotate that something can live as long as another thing, like a parameter. Not scope exactly.

Animats 12y ago
Right. When you give an object A a lifetime that makes it live as long as object B, you're effectively putting object A into the same scope, for memory allocation purposes, as object B. This works even if B is in an outer scope. This is a new, and very powerful concept. Any tutorial on this needs to be illustrated. Talking about line numbers is not enough.
- dbaupp 12y ago
  This... isn't how lifetimes work. As I said above, there's no lifetime annotations you can use to ensure that y lives as long(aka is in the same scope) as x in the following let x = 1; { let y = 2; } This is also true if you do dynamic allocations: there's fundamentally no way to "promote" variables to a higher scopes just by using lifetime annotations. Lifetimes are a purely passive thing, designed to allow the compiler to check the programmer's use of references, not to allow the compiler to massage things around to ensure that whatever use work. That is, if a Rust program compiles, then it will also compile (modulo needing extra `unsafe` annotation) and, importantly, do the same thing, if all the references are replaced with raw pointers, which don't have lifetimes to describe their relationships.
  - Animats 12y ago
    You're right. I thought you could use lifetime annotation to force something to be allocated in an outer scope. But Rust doesn't allow that.
dbaupp 12y ago
I sounded to me like Animats was describing an "active lifetime" system, where the compiler will change where variables are placed, when they are deallocated (etc.) to make whatever code work. Rust's lifetimes do not work like that.

Animats 12y ago

Right. When you give an object A a lifetime that makes it live as long as object B, you're effectively putting object A into the same scope, for memory allocation purposes, as object B. This works even if B is in an outer scope. This is a new, and very powerful concept. Any tutorial on this needs to be illustrated. Talking about line numbers is not enough.

dbaupp 12y ago
This... isn't how lifetimes work. As I said above, there's no lifetime annotations you can use to ensure that y lives as long(aka is in the same scope) as x in the following let x = 1; { let y = 2; } This is also true if you do dynamic allocations: there's fundamentally no way to "promote" variables to a higher scopes just by using lifetime annotations. Lifetimes are a purely passive thing, designed to allow the compiler to check the programmer's use of references, not to allow the compiler to massage things around to ensure that whatever use work. That is, if a Rust program compiles, then it will also compile (modulo needing extra `unsafe` annotation) and, importantly, do the same thing, if all the references are replaced with raw pointers, which don't have lifetimes to describe their relationships.
- Animats 12y ago
  You're right. I thought you could use lifetime annotation to force something to be allocated in an outer scope. But Rust doesn't allow that.

dbaupp 12y ago

I sounded to me like Animats was describing an "active lifetime" system, where the compiler will change where variables are placed, when they are deallocated (etc.) to make whatever code work. Rust's lifetimes do not work like that.