Specify temporary lifetime extension through expressions #2051

dianne · 2025-10-12T20:28:49Z

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.

dianne · 2025-10-12T20:33:36Z

src/destructors.md

 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:


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.

Yes, this greatly widens the definition of an extending expression, putting more load on the other rules.

dianne · 2025-10-12T20:36:23Z

src/destructors.md

-* 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].


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.

Let's see the admonition for this (with one or more examples).

I've handled this by making const block tail expressions no longer be defined as "extending" (along with let statement initializers and static/const item bodies). That way, there's less room for confusion, hopefully. I've also added an example of extending through a const block tail expression to illustrate it (taken from #2041)

dianne · 2025-10-12T20:55:36Z

src/destructors.md

+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].


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 program¹. 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 and consts #2041. ↩

Let's see the admonition that you have in mind here (with one or more examples). Let's also add rules to define what it means exactly to "extend to", "extend through", etc.

In particular, what it means to "extend through" a parent scope is going to be worth careful explanation and one or more examples in an admonition.

I've fully reworked the formulation of the upward walk from & expressions and added examples.

dianne · 2025-10-12T20:59:09Z

src/destructors.md

+```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() });
+```


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.

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.

This is all rather subtle. Erring on the side of more examples and explanation will be better here.

I haven't added additional examples for this case of lifetime extension yet, but I fleshed out the first one quite a bit to walk through what's going on. I removed the second in the process, but I'll think on how best to readd it later (along with negative examples).

dianne · 2025-10-12T21:06:26Z

src/destructors.md

+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]).


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.

Agreed they felt necessary here.

src/destructors.md

traviscross · 2025-10-12T21:38:22Z

Thanks @dianne; will have a look.

traviscross · 2025-10-28T22:46:42Z

@ehuss and I looked carefully through this today. Some thoughts.

After staring at this awhile, I see why this makes it easier to express the core idea of rust-lang/rust#146098 -- that the relative drop order within an expression should be consistent regardless of where that expression is. Expressing the rules inductively for defining an extending expression ends up pushing against this.

So it does, I think, make a deep sort of sense to drop the inductive approach, as this PR does.

At the same time, the inductive approach was carrying a lot of load. The reader could visualize walking down an expression, outside to inside, at each step checking whether it was still an extending expression. Then there was essentially one key rule that leaned on that:

The operand of an extending [borrow] expression has its [temporary scope] [extended].

What this PR does, in dropping the inductive framing, is to widen the definition of an extending expression significantly, and thereby put a lot more load on the rules that follow to narrow this back down. That's where it ends up getting a bit subtle. With this approach, both @ehuss and I found building intuition and checking the correctness of the rules to be more difficult. So, in dropping the inductive approach, I think we have some work to do in order to recover the same level of clarity.

Adding some !EXAMPLE admonitions that walk through applying these rules would help and be a good start here. It'll also be worth more carefully defining what it means to "extend to" or "extend through" something. The bit where we define some things as "extending through" but then "clamp" them so as to only "extend to" with the final rule ("A temporary scope extended through the scope of a non-extending expression is [extended] to that expression's [temporary scope].") is another bit of subtlety that it might be worth finding another way to express.

I'll leave some other thoughts inline.

traviscross · 2025-10-28T23:01:05Z

src/destructors.md

+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]).
+
+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].


This rule is particular is one where I wonder how we might do better. The idea, currently, is that the rules above define when a temporary scope would be "extended through" the scope of an expression, and then this rule says, well, if it's a non-extending expression, then we only "extend to" it.

I've reworked this to avoid the hack of using scopes to express hierarchy entirely.

traviscross · 2025-10-28T23:05:45Z

src/destructors.md

-The operand of an extending [borrow] expression has its [temporary scope] [extended].
+The [temporary scope] of the operand of a [borrow] expression is *extended through* the scope of the borrow expression.


It's a bit subtle that, after having defined above what is an extending expression, that this rule then doesn't use that definition at all. It makes sense -- all operands of any borrow expression are extending. But it'll be worth adding an admonition under each of these rules that elaborates the rationale and gives one or more examples.

I've reworked this: now it appears before the definition of extending expressions. It's difficult to provide admonitions and examples before defining all the relevant terms, but I've tried to connect the rules together and provided some detailed examples towards the end.

dianne · 2025-10-29T05:50:10Z

I'll try and address individual points soon, but first one higher-level note that I'll try to use as guidance when restructuring:

At the same time, the inductive approach was carrying a lot of load. The reader could visualize walking down an expression, outside to inside, at each step checking whether it was still an extending expression.

This PR's approach still has a visual intuition to it, so it should be presented in a way that makes that clear: instead of walking down an extending expression to check whether an &'s operand is extended, you walk up from an & and check whether you're in an extending expression at each step to determine the temporary scope of the &'s operand. Possibly a separate inductive definition would be useful for making that clear? Along with examples, of course. I was worried defining too many things all at once would make it difficult to follow, but examples should help.

traviscross · 2025-10-29T06:23:44Z

This PR's approach still has a visual intuition to it, so it should be presented in a way that makes that clear: instead of walking down an extending expression to check whether an &'s operand is extended, you walk up from an & and check whether you're in an extending expression at each step to determine the temporary scope of the &'s operand. Possibly a separate inductive definition would be useful for making that clear? Along with examples, of course.

Yes, exactly. This upward walk is what I'd been expecting but it has to be teased out a bit from the presentation here. Hopefully making that more clear will make the rules here more clear.

rustbot · 2025-11-03T07:29:02Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

dianne · 2025-11-03T07:29:59Z

I did a pass to clean up definitions, reframe "extending based on expressions" as a property of & expressions (rather than of extending expressions or let statements), and add clarification and examples. Some parts are still awkward, unfortunately. I've left review comments on a couple things in particular I'm not happy with yet.

dianne · 2025-11-03T07:31:21Z

src/destructors.md

 r[destructors.scope.lifetime-extension.exprs]
 #### Extending based on expressions

+r[destructors.scope.lifetime-extension.exprs.borrows]
+The [temporary scope] of the operand of a [borrow] expression is the *extended scope* of the operand expression, defined below.
+
+r[destructors.scope.lifetime-extension.exprs.super-macros]
+The [scope][temporary scope] of each [super temporary] of a [super macro call] expression is the extended scope of the super macro call expression.


Two things here:

I think it's helpful to start destructors.scope.lifetime-extension.exprs with a straightforward explanation of what all the definitions are for. Otherwise, I found that either too many definitions are needed before any of them can be explained, or the explanations have to refer to terms that haven't been defined yet. For the sake of directness, I moved destructors.scope.lifetime-extension.exprs.borrows to the start, but that meant having to refer to terms that are defined later. A possible alternative would be writing a new destructors.scope.lifetime-extension.exprs.intro rule, but when I tried that it felt redundant.

I don't love the term "extended scope", but I wasn't able to think of anything better, either in terms of naming or in terms of reframing to avoid defining it at all. I feel like it could probably also use some additional clarification but I'm still thinking of a good admonition to add for it.

dianne · 2025-11-03T07:33:44Z

src/destructors.md

 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:
+The extended scope of an expression is defined in terms of *extending expressions* and their *extending parents*. An extending expression is an expression which is one of the following:


Three things here:

To simplify the definitions of extending expressions and extended scopes, I've made let initializers, static/const items, and const block tails no longer extending. This might hurt the intuition of extending expressions a bit though.

I added the definition of "extending parent" when reworking the upwards walk. This keeps it rigorous without hacks (the parent of an expression isn't defined elsewhere, and going through the parent of a scope to save words is confusing). It also also makes it clear that extending expressions are all subexpressions and thus have parent expressions. But spending words on it feels a bit awkward too, either adding bloat or making things convoluted (or both).

Extending expressions are necessary to define extended scopes, but extended scopes are necessary to justify the definition of extending expressions. As such, I felt a need to connect this to the surrounding sections, but I don't love how it turned out. Maybe there's a better way to handle that.

Following up on making "extending parents" make more sense and making it clear that "extending expression" isn't a classification of expressions but a classification of subexpressions, maybe it would be worth renaming "extending expression" to "extending subexpression"? I think it makes more sense from a spec point of view, but it's more awkward to read and write (and it means having to adapt language elsewhere), so I haven't gone through with it.

It has some appeal, but I similarly see the problems you mention. If one says "extending subexpression", then one kind of wants the parent to be an "extending expression" (in the same way as "header", "subheader", etc.), but that's probably confusing.

dianne · 2025-11-04T16:37:30Z

src/destructors.md

+r[destructors.scope.lifetime-extension.sub-expressions]
+If a [borrow], [dereference][dereference expression], [field][field expression], or [tuple indexing expression] has an extended temporary scope, then so does its operand. If an [indexing expression] has an extended temporary scope, then the indexed expression also has an extended temporary scope.


I think this may need a terminology update, a carve-out in destructors.scope.lifetime-extension.exprs, or at least clarification on what "extended temporary scope" means. In particular, if you have an expression like

{ &*&temp() }

it's important that this rule takes precedence, so that temp() lives past the block. destructors.scope.lifetime-extension.exprs.borrows currently is worded to be the definitive lifetime of borrow operators' operands, but if only that was considered, temp() would be dropped at the end of the tail expression.

traviscross · 2025-11-04T21:35:25Z

We looked through this in the lang-docs office hours call today. The recent changes here are great. Big improvement in clarity. Thanks to @dianne for those.

We talked about how this might benefit from an introduction (perhaps in an admonition) to the "extending based on expressions" section that tries to give some intuition -- a reading guide -- to a reader coming into this section.

I'm going to give this another careful read through, and @ehuss is planning to run some tests with the PR to make sure the interaction of this with the 2024 edition change is clear, but overall, this seems really close.

dianne commented Oct 12, 2025

View reviewed changes

dianne marked this pull request as ready for review October 12, 2025 21:13

rustbot added the S-waiting-on-review Status: The marked PR is awaiting review from a maintainer label Oct 12, 2025

dianne mentioned this pull request Oct 12, 2025

Temporary lifetime extension for blocks rust-lang/rust#146098

Open

dianne changed the title ~~Specify lifetime extension through expressions~~ Specify temporary lifetime extension through expressions Oct 12, 2025

traviscross reviewed Oct 28, 2025

View reviewed changes

dianne added 2 commits November 2, 2025 23:27

Specify lifetime extension through expressions

e856ddf

Reframe lifetime extension to not be specific to let statements

596d282

This comment has been minimized.

Sign in to view

dianne force-pushed the uniform-lifetime-extension branch from 024f884 to 1fea72e Compare November 3, 2025 07:28

dianne commented Nov 3, 2025

View reviewed changes

dianne added 3 commits November 2, 2025 23:37

Reorganize, remove hacks, clarify, and add examples

71178bb

Add a couple examples where the spec didn't change

a0ae157

Adjust other references to extending expressions

e37d803

dianne force-pushed the uniform-lifetime-extension branch from 1fea72e to e37d803 Compare November 3, 2025 07:37

dianne commented Nov 4, 2025

View reviewed changes

		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].

		The operand of an extending [borrow] expression has its [temporary scope] [extended].
		The [temporary scope] of the operand of a [borrow] expression is extended through the scope of the borrow expression.

		r[destructors.scope.lifetime-extension.sub-expressions]
		If a [borrow], [dereference][dereference expression], [field][field expression], or [tuple indexing expression] has an extended temporary scope, then so does its operand. If an [indexing expression] has an extended temporary scope, then the indexed expression also has an extended temporary scope.

Specify temporary lifetime extension through expressions #2051

Are you sure you want to change the base?

Specify temporary lifetime extension through expressions #2051

Conversation

dianne commented Oct 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

traviscross commented Oct 12, 2025

Uh oh!

traviscross commented Oct 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dianne commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

traviscross commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Nov 3, 2025

Uh oh!

dianne commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dianne Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross commented Nov 4, 2025

dianne commented Oct 12, 2025 •

edited

Loading

traviscross Oct 28, 2025 •

edited

Loading

dianne commented Oct 29, 2025 •

edited

Loading

traviscross commented Oct 29, 2025 •

edited

Loading

dianne commented Nov 3, 2025 •

edited

Loading

traviscross Nov 5, 2025 •

edited

Loading

dianne Nov 4, 2025 •

edited

Loading