Specify temporary lifetime extension through expressions #2051
Conversation
| r[destructors.scope.lifetime-extension.exprs.extending] | ||
| For a let statement with an initializer, an *extending expression* is an | ||
| expression which is one of the following: | ||
| An *extending expression* is an expression which is one of the following: |
There was a problem hiding this comment.
A major change here: an extending expression is now any expression that preserves lifetime extension, defined non-inductively. I found this helps with generalizing the definition beyond let statement initializers, but I also often found myself having to refer to an expression being "extending when its parent is extending"; that's are now just an extending expression.
| * The operand of an extending [borrow] expression. | ||
| * The [super operands] of an extending [super macro call] expression. | ||
| * The operand(s) of an extending [array][array expression], [cast][cast | ||
| * The initializer expression of a `let` statement or the body expression of a [static][static item] or [constant item]. |
There was a problem hiding this comment.
Something slightly weird here: the last expression of a const block morally should be here, but it'd be a bit messy to have to exclude it from the rule for blocks lower down. Given that this definition of extending expressions doesn't care about where scopes are extended to, it shouldn't be a semantic issue, but it might warrant reformatting and/or an admonition.
| r[destructors.scope.lifetime-extension.exprs.parent] | ||
| If a temporary scope is extended through the scope of an extending expression, it is extended through that scope's [parent][destructors.scope.nesting]. |
There was a problem hiding this comment.
I struggled a bit with how to express this; in its current form it's a bit of a hack. Ideally, I feel like it wouldn't need to be a separate rule or to refer to the definition of scope nesting, but it's working around something subtle: by ensuring that expressions' temporary scopes are only extended by their scope-ancestors, we can work around const blocks having parent expressions that (to my understanding) shouldn't be considered ancestor scopes of the const block's body; temporaries extended by const blocks are extended to the end of the program1. Maybe there's a simpler way to express this, and regardless it could probably use an admonition.
I do think that some sort of "extended by" or "extended through" or "extending based on" relation is necessary though, regardless of how exactly we choose to define/present it. I feel there's too much ambiguity if we can't precisely associate expressions we're extending the temporary scopes of with the scopes they're being extended to.
Footnotes
-
This PR doesn't make all the changes needed to iron that out, but see Further specify temporary scoping for
statics andconsts #2041. ↩
| ```rust,edition2024 | ||
| # fn temp() {} | ||
| # fn use_temp(_: &()) {} | ||
| // The final expression of a block is extending. Since the block below | ||
| // is not itself extending, the temporary is extended to the block | ||
| // expression's temporary scope, ending at the semicolon. | ||
| use_temp({ &temp() }); | ||
| // As above, the final expressions of `if`/`else` blocks are | ||
| // extending, which extends the temporaries to the `if` expression's | ||
| // temporary scope. | ||
| use_temp(if true { &temp() } else { &temp() }); | ||
| ``` |
There was a problem hiding this comment.
Some additional examples would probably be good. Maybe it would help to have one where temporaries are extended through a block but not to the end of a statement? That could also be used as a compile_fail example.
There was a problem hiding this comment.
Maybe it could also use some additional text (or even an admonition?) to make clear the interaction with if block scopes and Rust 2024's tail expression scopes. I'm not sure exactly how much explaining is needed for that, though.
| r[destructors.scope.lifetime-extension.exprs.let] | ||
| A temporary scope extended through a `let` statement scope is [extended] to the scope of the block containing the `let` statement ([destructors.scope.lifetime-extension.let]). | ||
|
|
||
| r[destructors.scope.lifetime-extension.exprs.static] | ||
| A temporary scope extended through a [static][static item] or [constant item] scope or a [const block][const block expression] scope is [extended] to the end of the program ([destructors.scope.lifetime-extension.static]). |
There was a problem hiding this comment.
I wonder if there's a way to cut down on the duplication here. I felt these rules were necessary to be precise about where temporaries' scopes are extended to, but having them in the introduction to the lifetime extension feels necessary too.
| r[destructors.scope.lifetime-extension.exprs.other] | ||
| A temporary scope extended through the scope of a non-extending expression is [extended] to that expression's [temporary scope]. |
There was a problem hiding this comment.
Alternative to de-duplicating the above two rules, maybe there should be a more detailed section alongside destructors.scope.lifetime-extension.let and destructors.scope.lifetime-extension.static for this?
rustbot
added
the
S-waiting-on-review
dianne
changed the title
|
Thanks @dianne; will have a look. |
3 participants
Reference PR for rust-lang/rust#146098. This includes a reworked definition of extending expressions with the aim of expressing the new semantics more uniformly.