Lifetime dependencies #2750
Open
Lifetime dependencies #2750
+1,208
−0
Conversation
This file contains 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
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.
Update the free-standing function inference rules.
Added future directions: Function type syntax and closures
Add an alternative spelling: `lifetime` vs. `dependsOn`.
This section was a distraction. Changing the position of `dependsOn` for initializers is not something we need to consider initially.
Added the same-type inference rule.
@Lifetime annotation + simplified implicit lifetime dependencies
To clarify that the annotation refers to the parameter name, not the label.
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
|
@apple-fcloutier I think I fixed everything you noted, thanks! |
rjmccall
added
the
LSG
- `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
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
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.