Skip to content
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

Open
wants to merge 62 commits into
base: main
Choose a base branch
from

Conversation

tbkka
Copy link
Contributor

@tbkka tbkka commented Feb 5, 2024

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.

@tbkka tbkka changed the title Tbkka lifetime dependency Lifetime Dependency Annotations for Non-escapable Types Feb 5, 2024
@tbkka tbkka mentioned this pull request Feb 5, 2024
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
@tbkka
Copy link
Contributor Author

tbkka commented Mar 21, 2024

Overhauled to reflect a fundamentally different syntax. We now have a single @dependsOn(arg) marker that simply states the fact of the dependency rather than a set of borrow/mutate/consume/copy markers that state the type. This follows from conversation about the previous proposal: Since there is almost always only one type of dependency possible for any given function signature, we can simplify the syntax. This should also help users of libraries that expose nonescapable types: those users only need to know what values have dependencies; they generally do not need to be aware of the precise semantics underlying that dependency.

proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
proposals/NNNN-lifetime-dependency.md Outdated Show resolved Hide resolved
meg-gupta added a commit to meg-gupta/swift that referenced this pull request Mar 22, 2024
meg-gupta added a commit to meg-gupta/swift that referenced this pull request Mar 22, 2024
… 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.
meg-gupta added a commit to meg-gupta/swift that referenced this pull request Mar 22, 2024
… 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).
meg-gupta added a commit to meg-gupta/swift that referenced this pull request Mar 24, 2024
… 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.
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>) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func reassignWithArgDependence(_ span: dependsOn(arg) inout ContiguousArray<Int>, _ arg: ContiguousArray<Int>) {
func reassignWithArgDependence(_ span: dependsOn(arg) inout Span<Int>, _ arg: ContiguousArray<Int>) {

atrick and others added 15 commits June 20, 2024 16:08
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> {
Copy link
Member

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.

Suggested change
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`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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`.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LSG Contains topics under the domain of the Language Steering Group workgroup: blocked This proposal is blocked on some other consideration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants