Gregory's Server🦀 New #rustlang blog post! Learn about temporary lifetimes, about something called "temporary lifetime extension", and my idea for a new language feature called "super let".
 22 comments
@Mara I have a lot of headache with those currently at work - but in C++, where I don't have the borrow checker to detect dangling reference. So I'm currently introducing a temporary<T&&, Lifetime> type to implement the borrow checker in the library... @Mara How horrible would it be to infer this rather than require it to be written out? @tavianator To silently extend the lifetime of a `let` whenever necessary? I think that would result in the compiler silently accepting lots of code that shouldn't compile, hiding bugs and causing subtle unintended behavior. I don't think that's a good idea. ^^' @Mara @tavianator One worry I have (as a novice rust programmer who relies heavily on the very helpful error messages) is that if the compiler tells me "help: try using super let" then I'm probably going to press the "make my code compile" button without understanding the edge cases or consequences involved. So it may still cause some of these issues in practice? (thanks for the blog post - it was a really interesting read! :) @nyctef @tavianator I do think just adding "super" when the compiler suggests it works out fine in basically all cases! I just want it to be visible to a reader of the code, that something is going on with the lifetime of that object. Otherwise, it's very easy to hide a surprise in the code.  @Mara Using 'super' implies it is a modifier for what follows (à la const in C), which means it would/should be applicable in other circumstances, which would complicate parsing for just the single use case of 'let'…  @RealGene @Mara I don't see how The problem with Besides IMO it's nice that @RealGene The compiler can look at two words instead of just one, so that's no problem. ^^ `super let` is currently always an error, so nothing breaks if we give it meaning. So we can do that without needing a new edition. `make` is currently not a keyword and can be used as a regular identifier (e.g. variable or function name), so making that a keyword would break things and thus require an edition. @lorepozo Yes! Allowing `super let` at function level for functions that basically place additional values in the caller's stack frame would be useful! Then a function could create an object (in the caller's frame) and return something that references it, like a safe pin() would need to. That would need to be part of the function _signature_ though. I don't think we should (or can) allow any regular fn to start placing extra objects into the parent's scope. @Mara Super neat introduction to temporary lifetime extensions, which I think is one of those things that for the most part slide into the background and you don't _need_ to think about. Unsure about super let though, can definitely see the appeal, but not sure the upside is worth the extra complexity in the language.  @Mara I like the idea a lot. I ran into these quite a bit while learning rust. Thanks to this blog post I have a better appreciation for why it was so confusing at the time. Now that I know the rules I doubt I would opt into super-let very often but the ability of the compiler to suggest using this would build some educational content for how the borrow checker sees things into the tooling, which I'm almost always in favor of. Overloading `super` feels needless to me though. `ext(ended) let`? @swiftcoder Huh? The let binding is for the value that will be lifetime-extended. (It's no longer a "temporary" because it now has a name.) @swiftcoder Ah. Well, both? `super let a = Thing;` makes `a` live as long as the surrounding block. The lifetime that allows the block's final expression to be `&a`, basically. On top of that, we still have temporary lifetime extension, just like we have in a regular `let`: `let a = &temp();` makes the temporary life as long as `a`. Same for `super let a = &temp();`: the temporary will live as long as `a` (which might live longer than it would have in a regular `let`). |
@Mara yes! This would be super useful 🙂