-
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.
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 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
Here's one way such a value might be produced: | ||
|
||
```swift | ||
func mutatingSpan(to: inout ContiguousArray, count: Int) -> dependsOn(to) MutatingSpan<Element> { |
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.
Nit: to
is not a good name for a parameter in Swift; this greatly interferes with readability.
func mutatingSpan(to: inout ContiguousArray, count: Int) -> dependsOn(to) MutatingSpan<Element> { | |
func mutatingSpan(to target: inout ContiguousArray, count: Int) -> dependsOn(target) MutatingSpan<Element> { |
``` | ||
|
||
We’ve written this example as a free function rather than as a method to show how this annotation syntax can be used to express constraints that apply to a particular argument. | ||
The `dependsOn(to)` annotation indicates that the returned value depends on the argument named `to`. |
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.
The `dependsOn(to)` annotation indicates that the returned value depends on the argument named `to`. | |
The `dependsOn(target)` annotation indicates that the returned value depends on the argument named `target`. |
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.