Compile-time lifetime dependency annotations by atrick · Pull Request #3145 · swiftlang/swift-evolution

atrick · 2026-02-25T04:48:56Z

Propose a @lifetime attribute to explicitly annotate declarations that produce non-Escapable values.

This proposal is also intended to serve as documentation of the state of the compiler implementation of the experimental Lifetimes feature for early adopters.

Previous proposal: #2750

- Incorporate content from previous pitches - Reorganize proposal structure and flow - Add sections covering implicit defaults, closures, and lifetime requirements

meg-gupta · 2026-02-25T14:13:44Z

proposals/NNNN-lifetime-dependency.md

+In addition to function declarations, function types must support lifetime annotations so functions that return non-`Escapable` types can be passed as closures.
+
+```
+func foo(closure: @lifetime(borrow arg) (_ arg: Container) -> Span<T>) { ... }


This should be @_lifetime instead of @lifetime. Other examples need to be updated as well.

This is a proposal for the non-underscored syntax, so all the @_lifetime have been changed to @lifetime.

Of course, that's confusing to adopters using this as documentation. So maybe this should be explained in the introduction?

If adopters are using examples listed here to experiment, they may see confusing errors.

The proposal now mentions that the current implementation uses underscore. I believe adopters will get this warning
warning: Unsupported use of @lifetime, use @_lifetime to specify lifetime dependencies

Xazax-hun

I haven't looked at the detailed design yet, but have some questions inline.

Xazax-hun · 2026-02-26T15:49:06Z

proposals/NNNN-lifetime-dependency.md

+
+The `borrow` or `&` dependency specifiers indicate a scoped dependency on the argument. A scoped dependency must correspond to the argument's ownership:
+
+* A `borrow` dependency specifier requires `borrowing` ownership. It extends borrowing access, prohibiting mutations of the argument, but allowing other simultaneous borrowing accesses.


If borrow and & can only be used with one parameter convention, does that mean we have some redundancy in the syntax and we could get rid of some tokens?

Yes, the redundancy is intentional (in fact we added it later). We don't want the syntax to indicate that a mutable value is being "borrowed", as in @_lifetime(borrow x), because that normally implies a read-only shared borrow. The lifetime dependency only cares that there is either an immutable or mutable access scope, but programmers always think in terms of the parameter's ownership borrowing or inout.

Xazax-hun · 2026-02-26T15:55:59Z

proposals/NNNN-lifetime-dependency.md

+An `inout` parameter that is conditionally reassigned has two dependency sources:
+
+```swift
+@lifetime(span: copy span, copy another)


How is the syntax disambiguated when we also have a return type?
I.e., how the annotation would look like for:

func mayReassign(span: inout Span<Int>, to another: Span<Int>) -> Span<Int> { span = (...) ? span : another return another }

Or are we missing a span: after the comma?

Each target uses a separate @_lifetime attribute because they're really unrelated, so the target is only written once:
@lifetime(target: source1, source2)
I can see how that's confusing. hopefully the grammar makes it clear. This example is:

@lifetime(span: /*span ,*/ another) @lifetime(span, another) // if the result can be copied from either parameter func mayReassign(span: inout Span<Int>, to another: Span<Int>) -> Span<Int> {

Xazax-hun · 2026-02-26T15:59:12Z

proposals/NNNN-lifetime-dependency.md

+
+```swift
+struct Wrapper<Element: ~Escapable>: ~Escapable {
+  var element: Element {


Why do we require these lifetime annotations? Shouldn't these follow from substituting the generic argument for Element in generic code?

Yes, the lifetime attributes in that example are all the defaults. That's mentioned just below the example. I added a comment to the example too.

Xazax-hun · 2026-02-26T16:03:56Z

proposals/NNNN-lifetime-dependency.md

+_ = span
+```
+
+In the future, with additional syntax support, it may be possible for a function type to express dependenies simultaneously on both the closure value and its parameters. See "Closure capture dependency syntax".


What happens when a closure captures a Span or a MutableSpan? Does that have any implications on the escapability, copyability or any other properties of the closure?

The future direction "Fine-grained closure capture dependencies" has an example of a closure capturing a Span. It doesn't change much other than loosen the lifetime restriction on the captured value... the closure's result could outlive the captured span, as long as it doesn't outlive that span's dependency (the container that gave you the span)

Web4application · 2026-03-01T22:53:22Z

I hope all this is not from my device and if it is , or even if it’s another developer, you are tracking and updating privately without the person consent, is this how all of you do ? So most of this software was stolen and claimed. Anyway if this is from my database , stop it or I shut it down myself ,
Compensation for that developer who broke the barrier isn’t bad ? You all have enough , Atleast he deserves something
I this is from me , been long I detected the changes tho.
You can’t just sit waiting for an update from someone who’s working 24/7 on a research after getting it you all take the glory ,
Something must be done to all these

atrick changed the title ~~Consolidate, update, and expand the lifetime dependency proposal~~ Compile-time Lifetime Dependency Annotations Feb 25, 2026

Consolidate, update, and expand the lifetime dependency proposal

1ad4fd1

- Incorporate content from previous pitches - Reorganize proposal structure and flow - Add sections covering implicit defaults, closures, and lifetime requirements

atrick force-pushed the lifetime-dependency branch from de61433 to 1ad4fd1 Compare February 25, 2026 05:06

atrick changed the title ~~Compile-time Lifetime Dependency Annotations~~ Compile-time lifetime dependency annotations Feb 25, 2026

meg-gupta reviewed Feb 25, 2026

View reviewed changes

Xazax-hun reviewed Feb 26, 2026

View reviewed changes

Minor review feedback: mention the underscore and the defaults.

ede75ad

rjmccall added LSG Contains topics under the domain of the Language Steering Group new proposal Adds a new proposal document labels Mar 2, 2026

xwu mentioned this pull request Mar 9, 2026

Lifetime dependencies #2750

Closed


		The `borrow` or `&` dependency specifiers indicate a scoped dependency on the argument. A scoped dependency must correspond to the argument's ownership:

		* A `borrow` dependency specifier requires `borrowing` ownership. It extends borrowing access, prohibiting mutations of the argument, but allowing other simultaneous borrowing accesses.

Conversation

atrick commented Feb 25, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

Xazax-hun left a comment

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!

Choose a reason for hiding this comment

Uh oh!

Web4application commented Mar 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

atrick commented Feb 25, 2026 •

edited

Loading