Lifetime dependencies#2750
Closed
jckarter wants to merge 74 commits into
Closed
Conversation
We need to separate description of the dependency itself -- which places a bound on when particular objects can be destroyed -- from the syntax. In particular, the syntax specifies a relationship between two objects, but that relationship is not always a lifetime dependency itself (because of "copied" dependencies).
Also, fix the proposed syntax for properties
…bling proposal.
Changed `StorageView` and `BufferReference` to `Span` to match the si…
- Dependent parameters - Dependent properties - Conditional dependencies - Immortal lifetimes - Depending on immutable global variables - Depending on an escapable `BitwiseCopyable` value - Depending on an escapable `BitwiseCopyable` value
Remove Lifetime Dependencies for Computed Properties Remove Lifetime Dependencies between arguments
- Value component lifetime - Abstract lifetime components - Protocol lifetime requirements - Structural lifetime dependencies
Add several new sections
Add dependent parameters, immortal dependencies, and 'selfDependsOn'.
Update and cleanup the grammar.
Fix inference rules to be sequenced.
Update Future Direction: Lifetime dependence for closures
|
|
||
| ```swift | ||
| let array = getContiguousArrayWithData() | ||
| let buff = array.unsafeBufferPointer |
There was a problem hiding this comment.
I see that some declarations use @unsafe. Should these snippets be spelled let buff = unsafe array.unsafeBufferPointer?
| In generic contexts, `~Escapable` indicates that a type is *not required* to be `Escapable`, but is *not* a strict indication that a type is not `Escapable` at all. | ||
| Generic types can be conditionally `Escapable`, and type parameters to generic functions that are declared `~Escapable` can be given `Escapable` types as arguments. | ||
| This proposal refers to types in these situations as "potentially non-`Escapable`" types. | ||
| Return types that are potentially non-`Escapable` require lifetime dependencies to be specified, but when they are used in contexts where a value becomes `Escapable` due to the type parameters used, then those lifetime dependencies lose their effect, since |
| } | ||
| ``` | ||
|
|
||
| A dependence may be copied from a mutable (`inout`) variable, in this case the . |
| var a: Element | ||
| var b: Element | ||
|
|
||
| @lifetime(a, b) |
There was a problem hiding this comment.
Should specify the type of dependence
Contributor
Author
|
@apple-fcloutier I think I fixed everything you noted, thanks! |
rjmccall
added
the
LSG
glessard
reviewed
Mar 25, 2025
- `unsafeLifetime` is currently implemented as `_overrideLifetime` - Clarify distinction between using an inout parameter as a source or target, and point out what occurs (nothing) if a parameter is both the source and target of a dependency - Give an explicit example of conjoined dependence with multiple lifetimes on the same target
jckarter
force-pushed
the
tbkka-lifetime-dependency
branch
from
9ab1df6 to
5bc6202
Compare
Thanks @glessard for catching these typos! Co-authored-by: Guillaume Lessard <glessard@tffenterprises.com>
- Parameters are referred to by their internal binding name as target or source of a dependency - No effect on function types yet - Unsafe dependencies are specifically on `Escapable & BitwiseCopyable` types - Removed misleading example
glessard
added a commit
to glessard/swift
that referenced
this pull request
Apr 30, 2025
These are discussed in the lifetime annotations pitch: swiftlang/swift-evolution#2750 Addresses rdar://150400414
This was referenced Apr 30, 2025
glessard
added a commit
to glessard/swift
that referenced
this pull request
May 8, 2025
These are discussed in the lifetime annotations pitch: swiftlang/swift-evolution#2750 Addresses rdar://150400414
Catfish-Man
pushed a commit
to swiftlang/swift
that referenced
this pull request
May 15, 2025
These are discussed in the lifetime annotations pitch: swiftlang/swift-evolution#2750 Addresses rdar://150400414
Replace @Lifetime with @_lifetime in the lifetime dependency proposal
Contributor
|
Closing this as superseded by #3146. |
Contributor
|
(#3145) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Propose a
@lifetimeattribute to explicitly annotate declarations that produce non-Escapablevalues.This proposal is also intended to serve as documentation of the state of the compiler implementation of the
LifetimeDependenceexperimental feature for early adopters.