3 ms·
Rust must statically prove lifetime of references to stack allocated variables does not exceed lifetime of the variables they point to at compile time, in order
by pkolaczk 12y ago
Rust must statically prove lifetime of references to stack allocated variables does not exceed lifetime of the variables they point to at compile time, in order to be 100% memory safe. How is that different than just an advanced escape anlysis? Theoretically a VM could do much more, because it could do speculative escape analysis (I heard Azul guys were working on such experimental thing called escape detection) and even move variables from stack to heap once it turns out they do escape.
- tomp 12y agoYou could do escape analysis equivalent to Rust's only if you inlined all the functions. Sometimes, that's simply not possible, e.g. with separate compilation. On the other hand, Rust is still able to perform its kind of escape analysis (via lifetime-tracking type system), because the relevant facts are embedded in type signatures of Rust functions, and as such must be present even for separate compilation (even if the actual implementation of the function is unknown).
- pkolaczk 12y agoVM could do see all the functions and do whole-program analysis. Inlining is an orthogonal concept.
- pcwalton 12y agoYou could in theory, but that analysis would likely be really slow. In any case, without the type system and compiler to enforce the discipline the programmer is going to lose a lot of control and predictability.
- wtetzner 12y agoFor one thing, Rust can reject programs at compile time if it's not satisfied with its analysis. For Ruby to get that, you might have to restrict the language in a similar way.