4 ms·
Non-Lexical Lifetimes Based on Liveness in Rust
- killercup 10y agoThe introductory post [1] was also discussed here [2]. [1]: http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/ http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-... [2]: https://news.ycombinator.com/item?id=11611436 https://news.ycombinator.com/item?id=11611436
- sspiff 10y agoI wonder how clear error messages for this kind of liveness checking will be. Will they be able to point to variable usage that causes a variable to be locked?
- chrismorgan 10y agoThe Rust team is committed to having high-quality error messages in rustc, and its lifetime error messages are singularly superb, making a complex concept understandable and explaining in very thorough detail when necessary what is causing a problem: “this expected this because of this but found this which would mean that instead” with detailed diagnostics of the points in question, and such things. This tradition will not be forsaken with non-lexical lifetimes.
- cmrx64 10y agoI don't think anyone cares more about good error messages for this class of errors than Niko. The error messages are already pretty good today, pointing to precisely where a location was borrowed, and I'm sure it won't be allowed to regress, only improve.
- killercup 10y agoJust yesterday an overhaul of the style of the error messages landed (should be in the next nightly). It doesn't change the actual messages, but should make thinks like scopes clearer. You can find a few screenshots in the PR: https://github.com/rust-lang/rust/pull/32756#issuecomment-207095555 https://github.com/rust-lang/rust/pull/32756#issuecomment-20...
- JulianMorrison 10y agoThis strikes me as a bad idea prone to action-at-a-distance. let a = 1 let b = pointer to a do_stuff(b) do_other_stuff (a) is legal but suddenly becomes illegal when you turn it into let a = 1 let b = pointer to a do_stuff(b) do_other_stuff (a) // ... etc etc do_more_stuff(b) You add a legal statement down the function for a variable that's still valid and in scope, and the calls above it go kablooey.
- the_mitsuhiko 10y agoThat is already the case anyways.
- JulianMorrison 10y agoIf I understand the article, what's already the case is that any reuse of "a" while "b" exists is illegal. Which is simple and uncomplicated and you can work around it like this let a = 1 begin block scope { let b = pointer to a do_stuff(b) } // end block scope and b is dead do_other_stuff (a) What the change would do is make that block scope exist, but it exists implicitly and invisibly. And it invisibly stretches over the call to do_other_stuff(a) by the insertion of the do_more_stuff(b) below it. And suddenly it breaks. Contrast: let a = 1 begin block scope { let b = pointer to a do_stuff(b) } // end block scope and b is dead do_other_stuff (a) // ... etc etc do_more_stuff(b) // is obviously broken, b is not in scope or let a = 1 begin block scope { let b = pointer to a do_stuff(b) do_other_stuff (a) // is obviously broken, b is not dead // ... etc etc do_more_stuff(b) } // end block scope way down here
- kibwen 10y agoGiven that the Rust team is committed to introducing non-lexical lifetimes backwards-compatibly, by definition that means that no code that compiles today will be invalidated by the feature's addition. Which means that the only instances of concern being raised here are programs which are already invalid in today's Rust, which is to say that any workarounds for these theoretical problems are already mandatory. There's nothing "breaking" here that isn't already broken. It's a strict reduction in the number of programs that will be rejected by the borrow checker.
- Joof 10y agoIs this coming out of Rust's intermediate stage before LLVM? The compiler project seems to have gotten a lot more interesting :)
- steveklabnik 10y agoMIR will make this much easier to implement, so we're blocking it on MIR, yes.
- kinkdr 10y agoPersonal opinion, but I would rather be given a way to explicitly define(or in that case "undefined") the lifetime, rather than having the compiler trying to be smart. I.e let slice = ... capitalize(slice); "unlet" slice // <- explicitly make it go out of scope
- kinkdr 10y agoOr if you don't want to introduce a new keyword just use "let slice", which shadows the first "slice", and hence making it go out of scope.