-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lifetime Dependency Annotations for Non-escapable Types #2305
base: main
Are you sure you want to change the base?
Conversation
Overhauled to reflect a fundamentally different syntax. We now have a single |
… pitch Pitch - swiftlang/swift-evolution#2305 Changes highlights: @dependsOn(paramName) and @dependsOn(scoped argName) syntax @dependsOn(paramName) -> copy lifetime dependence for all parameters/self except when we have Escapable parameters/self, we assign scope lifetime dependence. Allow lifetime dependence on parameters without ownership modifier. Always infer copy lifetime dependence except when we have Escapable parameters/self, we infer scope lifetime dependence. Allow lifetime dependence inference on parameters without ownership modifier.
… pitch Pitch - swiftlang/swift-evolution#2305 Changes highlights: @dependsOn(paramName) and @dependsOn(scoped argName) syntax @dependsOn(paramName) -> copy lifetime dependence for all parameters/self except when we have Escapable parameters/self, we assign scope lifetime dependence. Allow lifetime dependence on parameters without ownership modifier. Always infer copy lifetime dependence except when we have Escapable parameters/self, we infer scope lifetime dependence. Allow lifetime dependence inference on parameters without ownership modifier.
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).
… pitch Pitch - swiftlang/swift-evolution#2305 Changes highlights: dependsOn(paramName) and dependsOn(scoped argName) syntax dependsOn(paramName) -> copy lifetime dependence for all parameters/self except when we have Escapable parameters/self, we assign scope lifetime dependence. Allow lifetime dependence on parameters without ownership modifier. Always infer copy lifetime dependence except when we have Escapable parameters/self, we infer scope lifetime dependence. Allow lifetime dependence inference on parameters without ownership modifier.
Add several new sections
Add dependent parameters, immortal dependencies, and 'selfDependsOn'.
Update and cleanup the grammar.
to disable lifetime dependence checking
The examples all refer to a `span()` function. This is unimplementable for `Array` because it might not have contiguous storage. An `Array` span requires a `_read` accessor because we need to create a temporary copy of the Array when it is discontiguous. But we can't talk about `_read` here because it hasn't been proposed yet.
Lifetime dependency
Fix a grammar typo.
If a function takes a nonescapable 'inout' argument, it may only reassign that argument if it is marked dependent on another function argument that provies the source of the dependence. | ||
|
||
```swift | ||
func reassignWithArgDependence(_ span: dependsOn(arg) inout ContiguousArray<Int>, _ arg: ContiguousArray<Int>) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
func reassignWithArgDependence(_ span: dependsOn(arg) inout ContiguousArray<Int>, _ arg: ContiguousArray<Int>) { | |
func reassignWithArgDependence(_ span: dependsOn(arg) inout Span<Int>, _ arg: ContiguousArray<Int>) { |
Update the free-standing function inference rules.
Added future directions: Function type syntax and closures
Add an alternative spelling: `lifetime` vs. `dependsOn`.
This is a companion proposal to "Non-Escapable Types".
It proposes a set of annotations that can be used to relate the lifetimes of two objects. For example, this can be used to ensure that a "slice" or "iterator" object that holds a pointer into some container does not outlive the container.