Recent searches
Search options
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".
@Mara yes! This would be super useful 
@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
I nominate "make" as the keyword for "super let". 'let' is passive, 'make' is active.
The intention to the compiler is clearer, and it certainly reads/scans better.
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 super let would complicate parsing. Rust parser has to do some weird things, but this is not one of them.
The problem with make is that it's not a reserved keyword, so we'd need to introduce a new keyword in an edition, use ugly k# in previous ones and also disallow people from using it for names. A lot of noticeable disadvantages.
Besides IMO it's nice that super is reading as a modifier, it should help teaching "this is like let but with a small twist..."
@wffl @Mara
IANAL but: super is already in use as a keyword/adjective to identify a module parent.
So now the parser must distinguish between 'super let' and 'super::let'.
The behavior described for super let doesn't yet exist anyway, so a new release would be required regardless.
So add 'make' as a super let, or 'durable' or 'perpetual' as a let modifier when you add the functionality…
You want a modifier to at least hint at what it's going to do. Super is kind of vague.
@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.
@Mara I like this idea, helps with what feels like gymnastics in several situations. Especially helps as a learning opportunity on temporary lifetime extension to help demystify rust. A natural extension would be for function bodies to use "super let", so that `pin!` could be a [safe] function. I hit this problem much more often than the nested blocks in your exposition. Though that sounds like an advanced form of "placement" so there might be a lot wrapped into there. But it would be good to consider how this feature may evolve longer term such as for those use cases. Syntactically I think the use of "super" here is clever in a good way — an alternative syntax might involve explicit lifetimes but any options that come to my mind there feel needlessly verbose.
@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.
@lorepozo I've added a small aside about this to the blog post.
@Mara if we really implement that, I pledge to instate a clippy lint to deny super let on any Mutex type. We definitely don't need mental gymnastics around those.
@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 hey listen we already have a heavily abused contextful keyword
"for let" 2024
@Mara great writeup! Perhaps alternative syntax `let(super) file = ...` would work kinda like existing `pub(super) ...` visibility.
@alexbigab @Mara Adding to this let(super::super), etc. for nested blocks, let(self) as alias for let and let('foobar) using https://doc.rust-lang.org/rust-by-example/flow_control/loop/nested.html, which should be available for arbitrary blocks, not just loops.
@Mara thanks, i learnt a lot! One minor nit - you have `if vebose {` twice. Thanks!
@nyurik Thanks! Fixed!